Qualifier length in SERIN command

westaust55

Moderator
That thread you link to is in relation to the NKM encoder/decoder. Those NKM2401 modules only supports packets of exactly 8 bytes;

Thus the comment by hippy at the time is in relation to the NKM encoder/decoder system:
The length of qualifier depends on how much data is being sent but the longer the better ( within the total 8 byte limit ). Every extra byte of data sent should take one off the qualifier.
I am not aware of any qualifier byte count limitation for "normal" SERIN commands and a quick check with 50 bytes as a qualifier in PE6 passes syntax for M2 and X2 parts.


The RFIN and RFOUT commands have a similar 8 byte limitation per packet:
Information:
The rfin command decodes and receives 8 bytes of data transmitter over a radio link from a NKM2401 encoder or rfout command from another PICAXE chip.
This provides much more reliable radio communication than using serin commands with low cost RF modules.
 

premelec

Senior Member
OK thanks... I wasn't clear that it was only with the manchester coding... I can send haiku qualifiers ;-0 - and was considering using time stamp on qualifier to provide some security [ re synced with transmitter].
 

hippy

Technical Support
Staff member
The qualifiers don't have a length, are just bytes with an indicator whether another byte follows or the end has been reached.

So, in theory, qualifiers can be of unlimited length, up to running out of program memory.

In practice there may be compiler limitations on length of line but the length allowed will still be more than would ever be sensibly used as a qualifier.

For qualifier matching for dumb RF comms, the qualifier should not be too long because the longer the transmission continues the more likely the receiver will lose its ability to track the transmission and, when that happens, data is more likely to become corrupted.

That also applies to the data itself. It is one of the limitations of using dumb RF modules and SEROUT and SERIN. If there is a lot of data it is best to split it into shorter packets and make multiple transmissions, combine those parts into one message after receipt.
 

Jeremy Harris

Senior Member
That also applies to the data itself. It is one of the limitations of using dumb RF modules and SEROUT and SERIN. If there is a lot of data it is best to split it into shorter packets and make multiple transmissions, combine those parts into one message after receipt.
I've just discovered that not doing this was the reason I had problems getting the VDrive2 module to work reliably. A few years ago I spent hours trying to make the VDrive2 work with the environmental data logger I built, and ended up giving up and switching to using the OpenLog µSD card modules, then later the SDLogger, SD card module. This week I started looking again at the VDrive2 and have found that it just doesn't work reliably if packets of more than around a dozen bytes are sent at once. It's taken me two solid days of trying to find this out, as the failure to write data to a USB stick, and return the prompt on completion, was seemingly random; it would often work for hours without failing, then just lock up.

Easy to fix by just breaking transmissions up into shorter packets, but very time consuming finding out that this was the cause of the problem!
 

Goeytex

Senior Member
Qualifiers can be tricky... At certain baud rate/chip speed combinations long qualifiers are likely to fail. This is due to the time it takes to test the received byte then move on to receive the next byte. This is especially true when the sending device does not add latency between bytes sent and specifically uses 1 stop bit.

For long qualifiers, the best chance of success can be achieved by using the highest Picaxe chip speed allowed by the selected baud rate. Eg, Long qualifiers will fail miserably with 9600 baud and chip speed of 8 Mhz. However they seem to work OK at 9600 and a chip speed of either 32 or 64 MHz.

Software serial Picaxe to Picaxe comms generally work better than "Other devices" to Picaxe "serin" comms, because with "serout" Rev-Ed has added latency between sent bytes to help out with the processing overhead limitations of serin.
 

premelec

Senior Member
Great advice all; could you suggest what a 'reasonable' 'appropriate' qualifier length would be in a slow rate [2400Baud ] system - perhaps maximum of 16 bytes? RF to RF... thanks...
 

hippy

Technical Support
Staff member
Great advice all; could you suggest what a 'reasonable' 'appropriate' qualifier length would be in a slow rate [2400Baud ] system - perhaps maximum of 16 bytes? RF to RF... thanks...
More than one but less than lots. I don't think there's any recommendation to be had because it all depends on the actual modules used and their antennas, how far apart and probably every other factor one can think of.
 

Goeytex

Senior Member
Great advice all; could you suggest what a 'reasonable' 'appropriate' qualifier length would be in a slow rate [2400Baud ] system - perhaps maximum of 16 bytes? RF to RF... thanks...
Anywhere from 1 to 4 bytes should be adequate for most applications. Consider that 4 bytes = 32 bits of "security". Why would you need more ?
 

Jeremy Harris

Senior Member
More than one but less than lots. I don't think there's any recommendation to be had because it all depends on the actual modules used and their antennas, how far apart and probably every other factor one can think of.

It's very little help in this case, I suspect, but by experiment I've found that, with a clock frequency of 16 MHz, and a baud rate of 2400, transmitting serial data to a VDrive2 (with the VDrive2 firmware changed to lower the default baudrate) I can't reliably transmit more than about 14 bytes. 20 bytes always gives failures after a few dozen transmissions, 12 bytes hasn't given a receive failure yet after 20 or so hours of continuous testing.

It's almost certainly not applicable to the case of what would be reliable as a qualifier length, but I have used qualifiers with HC-12 433 MHz modules of 8 characters and they have been very reliable for many months of continuous operation now.
 

premelec

Senior Member
Great information - thanks all... and to you moderators perhaps some summary of this info could be included in the SERIN command definition... It's on to the hardware for me... ;-0
 
Top