SERIN missing data

[BDG]

Hi,
I've been trying to write some code to read data from the serial port of a solar inverter.
The data is available by polling the inverter with a command string (8 bytes).
The Picaxe (18X) sucessfully sends the correct data string to prompt a reply. I can see the reply in a terminal (10 bytes: $80$80$80$dd$dd$dd$dd$dd$dd$cs) I am using a eavesdrop cable to watch what the Picaxe is seeing.
The data being recieved by the Picaxe is not all there. In fact I was expecting many more bytes (10) but the Picaxe would get stuck waiting for them all as its only seeing only getting 3 bytes (about every 3rd or 4th). I'm running athe the slowest data rate the inverter can support (2400) and here's the relevant code snippet:

ReadInv: ' Read data from inverter
	SerTxD ("Poll ")
	SerOut InvOutPort,N2400,($80,$80,$80,$00,$01,$01,$10,$12)
	for Number = 1 to DataLength
		'high LED 
		SerIn InvInPort,N2400,InChar
		'low LED 
		Write Number,Inchar 'store it temporarily
	Next Number
	Gosub RdTime
	Gosub ReadData ' retrieve data to display
Return

Any ideas how I could speed things up a little?

 

[Dippy]

The usual causes of fault (other than code error) are speed and timing.
And this is an example of the latter i suspect.

In your code you read the data byte-at-a-time in a loop. Bad. Unless you have a very fast device, this is potetnially doomed to failure*.
To make the situation worse you spend time storing the Data byte and THEN read again.

The 'sender' will be banging out serial data all the time.

So, your code reads the first byte, and while faffing about storing and then getting ready for the next byte, the 'sender' has already sent it.

I suspect that you probably get the correct bytes now and then.

A 'hippy analogy' (hipalogy) would be trying to listen to somone over the phone and while they are taking you re passing the instructions onto someone else. So while you are relaying the message, they are still talking and you miss bits.
Whereas the best thing to do is listen to the whole message and then pass it on.

You will have to Serin with 10 byte variables in a single command to stand a chance.
OR Better, get yourself an X1 which can do background receive.
In a few years time, you will probably be able to use an X2.

*Actually I use a similar method with 'another' processor, but as it runs 100 times faster then it isn't a problem.

 

[hippy]

As Dippy says; "speed and timing"

The WRITE between SERIN's will take around 5ms so that will cause data to be missed, plus the delay between sending the SEROUT and the SERIN could lose the first character or more.

You probably want to use POKE rather than WRITE because that's faster, then move what's been stored in SFR to EPROM once all data has been read. Also run at 8MHz and use N1200 to achieve the same 2400 baud comms.

 

[Dippy]

I would have thought that ANY PICAXE BASIC command would have messed up a read loop.

Unless you can reduce the baud rate (and you said you were at the slowest) then this loop read for 10 bytes is potentially doomed.
Even your looping probably introduces too much delay.
Try a 10 byte Serin.
Experiment dear boy... experiment....

 

[hippy]

I've had a PICAXE reading back-to-back serial bytes from a PC, poking to an SFR buffer, checking for CR and if not repeating. I recall that was at 8MHz and couldn't get over 1200 baud ( and that may have been with forcing two stop bits on send ).

The problem is that with back-to-back serial at 2400 baud there may only be 400us to store the data received and be back at SERIN ready for the next.

SERIN with the right number of bytes should work. Alternatively consider the 28X1/40X1 with its high-speed serial.

 

[moxhamj]

This has already been said, but just to say it again in another way, if you have less than 14 bytes you can read them in as a group with

serin b0,b1,b2 etc

(Check the manual for the correct syntax). That will certainly work at 2400 baud.

Then you can write the bytes to eeprom at your leisure.

 

[BDG]

Thanks heaps guys,
The read 10 byte at a time scenario works a treat. I hadn't realised you could do this (all I had to do was to scan down the page a bit more- 2 more lines- to realise this)
Yes it works just fine at 2400bps, I had it running for a every 5 seconds for few hour and it didn't miss a beat!
Thanks

Now I just have to work out how to get this VDrive2 to cooperate!