Wireless Communication -- Send Raw Data or Results?

[jpanhalt]

I am now at the point of connecting my accelerometer tilt sensor to a display wirelessly. My two most recent blog entries describe both elements of the project. Here is a link to the display blog (https://www.electro-tech-online.com...aracter-display-16f1519-nhd12864mz-mpasm.html).

I have a couple of XBee modules that will be used, at least initially (AT mode). Coding is in MPASM.

The accelerometer produces a square wave, the duty cycle of which correlates to tilt. I am measuring duty cycle by collecting high counts and total counts using the 16-bit TMR1 module of a 12F683.

My question is whether common practices would have me send the raw data (i.e., 4 bytes of data for each axis) and do all calculations in the display unit or pre-process in the 12F683 and send results (e.g., tilts) as ASCII character data to the display unit.

Data rate is fairly slow (100 Hz), the graphical display is not very complex, and I don't see the need for co-processing. Sending raw data could be faster (will probably use 9600 baud).

The concern I have with sending raw data is that an undetected error in transmission might be less likely to give an unreasonable result for display than if the error occurred in transmitting the calculated results in ASCII. Are modern links, like XBee, good enough that such errors are not really a concern. Is my assumption about error detection valid?

Any other comments or guidance on this question?

Regards,

John

 

[Mr RB]

...
Data rate is fairly slow (100 Hz), the graphical display is not very complex, and I don't see the need for co-processing. Sending raw data could be faster (will probably use 9600 baud).
...

I think you might be pushing it for datarate there, what are the RF conditions, ie distance, obstructions etc?

If your module will reliably do 9600 baud, that is 960 bytes per sec and allowing for gaps between packages etc and larger stop bits for reliability then 100 packets per sec get maybe 6 bytes per packet.

Each packet will need a preamble (of a few bytes?) plus 1 or more bytes for a checksum. A 2 byte Fletcher checksum is very fast to implement.

So that hardware performance will determine the best way to format data for transmission. You might be better off sending less packets but larger size, and multiple samples in each packet? And you're always better off sending less bytes, so pre formatting the data into a smaller size is good before transmission.

 

[misterT]

The concern I have with sending raw data is that an undetected error in transmission might be less likely to give an unreasonable result for display than if the error occurred in transmitting the calculated results in ASCII. Are modern links, like XBee, good enough that such errors are not really a concern. Is my assumption about error detection valid?

I would just send the raw data. There is error checking in the RF link of XBee, so all received data should be guaranteed to be correct. There can be errors in transmission between uC and XBee though.. so you should put a simple error-checking code in your data packets, like MrRB already said.

 

[jpanhalt]

The 100 Hz I mentioned is the frequency of the sensor. The raw data is just 4 bytes. Total counts is about 10,000 (PIC12F683 runs at 4 MHz); high counts are between 4000 and 6000. I was thinking of summing 4 or 5 cycles and sending that every 100 mS or so to keep to 4 bytes plus overhead. Display update frequency will be determined empirically.

I was strongly leaning toward sending the raw data and will now continue in that direction. Thank you both for the input.

John