GenBoard/LoggerIntegration/DataFormat

For developers

Quintessence continued on http://wiki.x-dsl.hu/cgi-bin/w/telemetry.cgi?UartPacketComm.

Datalogger discussion/specs

Simple HW device with

psd-256-01.jpg

Software specs:

Discussion below is history


Types of data


Storage locations


Data format

The data should be effectively addressed by type, and metadata, not by location (currently the EEPROM has the structures exactly in the same layout as in SRAM). This can be solved by frame-descriptors that help format and interpret the frames (in the PC and in the ECM)

This allows servicing dynamic demands. Some want huuuge tables while others want more learnt values or runtime logs.

This associates with some kind of filesystem.


Lightweigth filesystem - this is obsolete, see the frame-based thingy in GenBoard/BinaryProtocol

I thought of small blocks of binary data:

Something similar is needed when sending data over the network to other GenBoard, PC or friendly unit. The frame also has to identify

However some of these can be in a secondary header (only over the network, not in storage), somewhat similar as TCP and IP headers.

16..17 bytes metadata would allow more flexibility than 8 bytes.

We should leave some room for future expansion (the units later will allow much higher bandwidth, and more memory and cycles), and at least we want to detect communication incompatibility (with future products).

Please take a few minutes googling around. I used keywords

lightweight frame data protocol microcontroller

but only found TinyOs? that could be usable: implemented on AVR - from 8513 having only 512 bytes RAM - and actually very similar to our EventQueue? and userspace mainloop system, but TinyOs? supports advanced communications.


Metainfo fields

That way it's easy to move around stuff, cause it's not addressed by location.

Something like this is essential for MMC, where several type of info can be stored. You will later want to evaluate with the PC, and the PC must know what type of data it reads. We don't want to restrict just to one infotype (eg. logs or learnt data), it's better to allow storing any type that's necessary.


Learnt data

Learnt data is a bit special, because it's best to store it in EEPROM the latest possible time, just before powerdown (writing it all the time wears EEPROM a bit).

See GenBoard/BackupPower for some discussion on solutions, some including hardware.

An acceptable software-only solution can be to start saving randomly or equal-time (table-elements that are differ from saved value above a threshold) after 25 minutes of running if the learning is enabled.

If the VE learned data moves around in EEPROM in time, saving a byte every 10 second should get a long EEPROM life:


See also