Hser background with preamble

techElder

Well-known member
There's a lot of discussion on here about preambles ($55$55 or "UU") with wireless serial comms, but I'm confused about the reception of preambles with wired connections.

I'm using an interrupt driven background hser procedure that works great due to a perfect test connection so its hard to find out what it will do with a lousy connection.

If I send a preamble of "UU", PAUSE, a QUALIFIER/ID and some data, that's exactly what I get in scratchpad memory. Easy to slog through the preamble and process the QUALIFIER with @ptr etc.

However, if the preamble gets partially scrambled, perhaps only receiving "U" and the rest of the packet is accurate, is that a case for abandoning the total packet? Didn't the 1's & 0's pattern of the preamble do its job and sync the hardware? In this case I won't know EXACTLY where the QUALIFIER is in scratchpad memory without scanning for it.

PS. I'm probably over-thinking this again. ;)
 

AllyCat

Senior Member
Hi,

if the preamble gets partially scrambled, perhaps only receiving "U" and the rest of the packet is accurate, is that a case for abandoning the total packet?
You need to ask youself why (or if) that might happen and if your data integrity is important.

IMHO with a wired connection the probabilty of errors is small. But if your data integrity is critical, then you should be considering aplying a check(sum) to the data. A checksum (byte) is easy to apply (using "+", or more commonly XOR, "^"), but there are many more sophisticated checking (such as a "CRC") or maybe correcting schemes (e.g. "Hamming") that can be used. It really depends how deep you want to go into the maths (which can be seriously advanced). :)

Cheers, Alan.
 

techElder

Well-known member
Actually, I've thought more on using MODBUS than anything else, so there's the CRC.

I suppose my question is more generic than specific in nature.

Perhaps the answer is in the difference between wired and wireless; the latter sitting there without a defined initial state.
 

hippy

Technical Support
Staff member
The specific sequence sent by the transmitter to pre-condition the receiver should help sort things out for you; a number of $55 bytes, a pause, the qualifier then data. That should ensure correct synchronisation at the start of the qualifier when scanning through the background receive buffer. Everything up to the qualifier may be noise or corrupted, but when ignored it won't matter.
 

lbenson

Senior Member
Whereas the preamble in a wireless connection is supposed to help the receiver start to discriminate a real transmission from background noise (as I understand it), I don't understand what value it would have in a wired connection.

Does your wired connection get a stream of random characters when nothing is transmitted as a "dumb" 433mHz receiver does? If so, the question might be why that happens, and whether another type of wire (shielded?, twisted pair?) or routing of wire might correct the problem.

A qualifier in a wired connection might help if there were multiple receivers, but if it were subject to corruption, how would its corruption or non-corruption help you to determine whether the actual message was corrupt or valid? It would seem to me that if a high degree of certainty were needed, either a CRC or at the least, sending inverted pairs (x, ^x, y, ^y, etc.) with checking of pairs would be needed. And then handshaking, if you needed to know that messages were not lost.

Have I understood correctly that your ultimate setup is to be wired, and not just the test setup?
 

techElder

Well-known member
Just trying to plan for possible contingencies. Yes, ultimately will be a wired connection.

However, as I see it, any time one has a serial link then a plan should be made for the eventual conversion into a wireless link. Perhaps there's no chance this wireless link will be implemented without all the bells and whistles (preamble, CRC, etc.) built in, but I don't want to hamper a future expansion now and have to undo it later.

I'd rather not program myself into a corner.

Thanks for the comment!
 

Pongo

Senior Member
Wired or wireless you need to handle a start up situation where one or other unit is up and running before the other. Here's another thread where I was working through a somewhat similar issue and Goeytex provided some code that was very helpful.
 

hippy

Technical Support
Staff member
Sorry; misread that this was for wired, not wireless.

In which case you don't need to send any preamble or pause as that is solely necessary for wireless.

Everything sent on a wired connection should be received correctly. So it's up to you whether you check preamble bytes or not. Doing so will help identify corruption, but if the actual payload is correct and only the preamble were corrupt you could end up throwing away a usable packet which could otherwise be used.

If there is other data validation ( packet size included with the packet, checksum etc ), I would probably discard the preamble and just verify all that. If not, I would be probably check the preamble, or at least a few bytes before the qualifier, are correct.
 

techElder

Well-known member
Pongo, yes I've read so many "hser preamble qualifier" threads on here looking for a definitive answer. (I call the post that you reference the "whoops" thread. :) )

Hippy has posted the definitive answer, but ...

In my case, I'm looking forward to RS485 (at least) where there will be at least one extra drop of the serial line. That means each drop will have to have a unique qualifier anyway, so I might as well build that in from the start.

So, with Hippy's and everyone's suggestions above, I'm only going to suggest a preamble on the sending end and scan for the qualifier on the receiving end in my wired connection.

Wired or wireless you need to handle a start up situation where one or other unit is up and running before the other. Here's another thread where I was working through a somewhat similar issue and Goeytex provided some code that was very helpful.
 
Top