trichl / TickTagOpenSource

MIT License
146 stars 17 forks source link

Discussion of technical tradeoffs? #2

Open JimJJewett opened 2 years ago

JimJJewett commented 2 years ago

Is there a detailed discussion of design tradeoffs somewhere? (I've read the journal article at https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0267730 and the project README.)

I was impressed that it made sense to choose a heavier GPS receiver in order to use a smaller battery, so you may well have considered the following as well, but ... I couldn't find the information.

Why use external flash memory instead of the LOCUS logging built in to the GPS chip used by the GPS module?

Why use a custom logging format? I assume it was to reduce memory memory usage, but then why not document how to customize it further, by dropping the last few bits (within the HDOP) or the first few (for animals not likely to leave the local area). Or by storing only differences from the previous fix, which should take fewer bits, at the cost of some software complexity.

Was the ATTiny needed, or would it have been reasonable to use just the GPS module? As best I could tell, this gave you more freedom for scheduled GPS fixes, but the combination of various low-power modes and conditional capture (including only when outside a home area, or moving faster than a certain speed) seemed like they might outweigh this in some cases.

What about just using the GPS chip (MTK 3337?) instead of a module (Quectel L70?) This might make it easier to get the right customizations on which data to save and when, but if it also required 5000 units or lots of hardware integration, that could explain why not...

trichl commented 2 years ago

Hey Jim,

good questions and a good idea :-) With new GPS chips it would for sure be possible to reduce the weight, but key point is the continuous power consumption. New interesting chips are for example the ublox MAX-M10M (max. 3.6V on backup line, means no possibility to use a lipo without LDO) or the YIC71009EBGG (no backup mode though).

I thought about using LOCUS, but it lacks flexibility (sampling schedules, burst recordings, ...) and can only store a maximum of ~3800 fixes. Custom logging format was implemented to reduce memory footprint of a fix without loosing accuracy. HDOP and other performance metrics are not stored alongside a fix, but as a summary only (average value of all fixes). Storing only differences might be an option to further compress the data! The software already integrates geo-fencing, in cases when animals are stationary and only excursions outside their home ranges are of interest.

In the first design approach I tried to use only the L70 without MCU, but it becomes extremely unhandy in the field (you need to send UART configuration messages before starting to record). I think a MCU gives way more flexibility.

Integrating a MTK 3337 or similar GPS chips would also be very interesting, but requires a lot of external components and is not easy (RF-wise).

Happy to keep on discussing.

Best, Timm

trichl commented 2 years ago

Sorry, accidentially closed the issue.