Spurious 0xff after timestamp (EL3500)

[steffen-AEI]

Having been a Linux guy for the past 25 years, I was very happy to find this code, which made it possible to read out an EL3500 that had been purchased about ten years ago (I still have a 512MB SDcard for it). Thank you!

After successfully recording over 4 days, and reading out the internal memory of my logger daily, I this morning found some very high wattage values reported by el4000.py.

A closer inspection showed that there had been two startcodes (nothing unusual), and following the second one and the corresponding timestamp, there was an extra 0xff byte inserted, This kind of desynchronisation obviously caused the nonsensical values.

Not very familiar with Python programming, I had to doctor the file using an editor - and removing the extra byte put me back on track, with completely sensible values. Phew ;)

Did this happen to others as well? Would it be correct to ignore any 0xff bytes in front of any 5-byte record? Is it perhaps too late to ask for a patch? - Thanks.

(I seem to be unable to upload the file in any format allowed. Please advise how to provide it.)

[Lekensteyn]

Hi Steffen!

I have not seen such behavior before, perhaps that is something specific to the older devices? I think that if you zip the file, you'll be able to upload it here.

Is it possible that the filesystem got corrupted? Can you reproduce the issue with a different SD card or files?

[steffen-AEI]

I have not seen such behavior before, perhaps that is something specific to the older devices? I think that if you zip the file, you'll be able to upload it here.

Tried everything, zip was not accepted. Will find a web service to host it, may take a few days though. It's exactly one 0xff byte at position 531 (decimal), removing it made the file work again.

Is it possible that the filesystem got corrupted? Can you reproduce the issue with a different SD card or files?

I'll try and re-transfer the data from the logger next week. Since this will write new files, the data corruption probably will go away if it's not kept in the logger's internal memory (don't know how recordings are stored internally). Since there's now an official description of the data format by Conrad, perhaps something (that would be allowed, as including one to three 0xff's in the data stream - the voltage bytes won't start with 0xff) was overlooked in the implementation (which I suppose was based on rev eng?). In any case, there'll be a follow-up! Thanks, S

[steffen-AEI]

Re filesystem corruption: indeed, the EL3500 seems to be prone to cause corruption to existing data structures (in particular affecting, and apparently limited to, subdirectories). The implementation of DOS filesystems seems to be rather rudimentary, documentation is sparse, and one can never be sure to have chosen the right parameters (in particular when using Linux) for a full format of the card.

A fresh readout was able to reproduce the inserted 0xFF byte (which therefore seems to be present in internal memory, or can be reliably reproduced by the code writing out the internal storage), and this time I found another source of desynchronization: missing bytes in the middle of a data stream (far away from header sequences), which are way harder to fix.

So it's possible that this device is reaching the end of its life - and as I seem to be unable to purchase fresh SD cards that would fit the requirements (the manual asks for min 512MB, max 2GB, 1GB recommended, using FAT32 - which would indeed impose a lower limit of 256MB), my current one had come with my first digital camera many years ago, and seen a lot of reformats since - it might also be a matter of SD card life.

OTOH, the SD card approaching its EOL would not explain extra or missing bytes...