[GTALUG] Serial logging: best practice, pitfalls, advice?

[Stewart C. Russell]

Thanks to all who responded!

On 14-09-16 02:45 PM, David Collier-Brown wrote:
>
> It's just a little redundant: the names end in : the values in , the
> time is in square brackets, the  rssi in round ones. 

Good point. I wonder if it's worth encoding each record as JSON, like:

{"Energy_Wh": 63856, "Temp_C": 14, "Rssi_dBm": -81, "Power_W": 613,
"Timestamp_ms": 105874810}

Readable, computer readable; maybe a little verbose, but definitely
self-describing.

> If the arduino has a clock, you might also start with
> *# Date and time, **Tue Sep 16 14:43:01 EDT 2014*

It doesn't, unfortunately; also, many Arduinos use ceramic resonators,
so their clock stability is pretty terrible. I'll have to assume that
the computer it's talking to has a decent RTC, and can use the system time.

===

On 14-09-16 03:04 PM, D. Hugh Redelmeier wrote:
>
> I'd be tempted to put some kind of checksum on each record.
> Communications has many ways of screwing up.

We're decoding someone else's protocol. The protocol, which a couple of
folks smarter than me reverse-engineered, does use CRC8 in its packets,
and uses multiple transmissions to get through. The transmit hardware is
quite nicely engineered: sealed case, decent Atmel transmitter hardware
with a proper loop antenna. The stock receiver uses those horrible cheap
OOK RF Radio modules, but works.

The RFM69 transceiver module I'm using as a receiver is rather nice;
built-in packet protocols, a decent on-chip buffer; even on-chip AES
encryption/decryption, should you need it.

> I'd encode it in ASCII graphics somehow (or even decimal) so that your
> format remains readable.

Oh I wish the developer had done this, but most ISM band transmissions
have to be super short, as the transmitter duty cycle is really low.
Plus, every single car remote, baby alarm and automatic light switch is
chirping away on the same frequency. I'm amazed any data gets through at
all!

cheers,
 Stewart