Data sync with AXE213 modules

A

Adrian Hudson

Member
Hi All,

I am using an AXE213 transmitter/receiver pair - everything working fine except one time the data got ot of sync. I am sending 8 byte "records" as one is supposed to do and somewhere along the way a couple of bytes got lost so the last couple of bytes of one record were transmitted with the first six of the next. This continued until I reset the sending picaxe and transmitter.

How do you avoid this happening and if it does happen how do you get things back in sync? I want to somehow tell the transmitter to throw away the contents of its internal buffer and start again before sending the next record.

Thanks in advance!
 
B

Basrad

Member
I'm not expert, so id wait to see what they say.. Some thoughts.. If you only have one way communications? how can you tell the transmitting side data was

If 1 way like a tv and IR remote. The tv will do nothing if a command can't be received in full.

alternatively if 2 way I'm thinking you'd need to use code check full data was received by some sort of comparing function. Then send a reply asking for the next set of data..

Alternatively I could be barking up the wrong tree.
 
Last edited:
B

Basrad

Member
Just checked data sheet. What added modules are you using? Says max transfer rate it 60 bytes a second.
 
S

srnet

Senior Member
Basrad makes a significant point, you say you are using a pair of AXE213, which implies one pair.

With only one pair of boards the transmitter has no way of knowing that the receiver has missed something.

So are you using one pair of board or two ?
 
W

westaust55

Moderator
It may help if you post your program code (Tx and Rx side) preferably in its entirety or at least advise what baud rate you are using for you project
 
hippy

hippy

Ex-Staff (retired)
Adrian Hudson said:
I am sending 8 byte "records" as one is supposed to do and somewhere along the way a couple of bytes got lost so the last couple of bytes of one record were transmitted with the first six of the next.
Click to expand...
The most likely scenario is that the receiving PICAXE started some time after the transmitting PICAXE, and when it grabbed 8 data bytes the receiving NKM2401 was part way through transferring data to the receiver. The SERIN grabbed what data was left to be sent ( 2 bytes ) and then the SERIN waited until it could read the last 6 bytes which would come as the first 6 bytes of the next packet the NKM2401 passed over.

Those problems can occur when the receiving PICAXE and receiving NKM2401 are operating asynchronously to each other. The best solutions are to either reset the NKM2401 ( by controlling its power ) then power it up and immediately enter SERIN, or use the handshake signals to flush packets and only enter SERIN when the NKM2401 has no packet to pass over. You could also wait for a packet, SERIN it with a timeout to determine only a partial packet were sent and throw that away.
 
C

crowland

Member
It's important to make sure that at least the start of each 8 byte packet can be identified, that way if you get out of step you can resynchronise. A good way to do this is to start each packet with a code value that cannot appear in the data.

My electronic compass is sending heading and battery voltage with a packet that starts with a 'h' character, three ascii numbers for the heading in degrees, a 'd' of 'x' to indicate if the heading is valid, a 'b' then two ascii numbers for the battery volts in 1/10 deg, so "h123db29" indicates a heading of 123 deg and a battery voltage of 2.9V.

The read code looks for the 'h', then reads and decodes the next 7 bytes. If data is missed then a packet may be lost but it will resynchronise on the next packet.

Chris
 
C

crowland

Member
It's important to make sure that at least the start of each 8 byte packet can be identified, that way if you get out of step you can resynchronise. A good way to do this is to start each packet with a code value that cannot appear in the data.

My electronic compass is sending heading and battery voltage with a packet that starts with a 'h' character, three ascii numbers for the heading in degrees, a 'd' of 'x' to indicate if the heading is valid, a 'b' then two ascii numbers for the battery volts in 1/10 deg, so "h123db29" indicates a heading of 123 deg and a battery voltage of 2.9V.

The read code looks for the 'h', then reads and decodes the next 7 bytes. If data is missed then a packet may be lost but it will resynchronise on the next packet.

Chris
 
You must log in or register to reply here.
Top