Requirements for AGT V2

[jerabaul29]

Hi @PaulZC ,

I have been using the global tracker quite a bit (not for balloons, but other applications), and suggesting these to several people around me. I think everybody is very happy about it (we have used something like 20 of them so far, and are waiting for them to get back into stock for buying more). I / we think there is quite a market for this "iridium + gps + MCU + power regulation + available SPI, I2C, and digital pins" configuration, and it is really amazing that you help drive things forward :) . Many people in geosciences are interested when I present what we do with these modules, so that may become a quite big market (I hope it will, as I guess this would drive down module costs and help improve code and libraries support for my use ^^ ).

I have collected a bit of use feedback, if this may be of interest to you. As a note, we are not interested in balloons, so for us smaller and lighter is a nice to have (as we can have smaller enclosures), but not a super high priority. I understand this may differ from user to user though :) . We are mostly interested in 1) ease of use (in particular power supply robustness), 2) power efficiency, 3) possibility to add stuff to the MCU (i.e. many pins and pads available).

But anyways, the main feedback so far:

• we miss a bit the presence of a step up / step down power converter. LDO is nice, but when using some "low peak power" Li cells (which have higher capacity at the cost of peak current), the voltage now and then drops a bit. Adding a step up / step down converter fixes things (and this is what we do), as well as provides more efficiency when feeding from 3xAA batteries. Would be great to have one on the board, as this would be a guarantee that things "just work" with a variety of batteries and fluctuating input voltage, and would take the burden of providing regulated input voltage off the user. I understand such converters have a tiny bit of quiescent current, but I think that we would be willing to pay this price. Also, I wonder if it would be possible to have a bit of electronics (a transistor or two probably) so that one can choose to either 1) feed from the battery directly (possibly through a small LDO for safety) turning off the step up step down converter (this is when the board is sleeping and only the Ambiq MCU, which needs low voltage and power anyways, needs power while sleeping), or 2) power from the step up step down when more power is needed, turning it on from the Ambiq in software when needed. Do you think something like this may be doable, with a capacitor or something like this to ensure smooth transition back and forth between both modes?

• we miss a bit having more pins from the Ambiq MCU being broken out. This is our main issue now. There is quite a bit of space left on the "periphery" of the board, and it would be amazing to "fill it up" with as many digital pins as possible. Adding some digital pin pads on the bottom of the board may be a possibility too :) . We would like both extra SPI / I2C / serial ports being broken out, some general GPIO pins, and maybe also the "high power driving" pins (the ones mentioned in section Pin Drive Strength here: https://learn.sparkfun.com/tutorials/designing-with-the-sparkfun-artemis ).

I was wondering if maybe @adamgarbo has some feedback of his own too :) .

[PaulZC]

Hi JR (@jerabaul29 ), This is really valuable feedback - thank you. Tagging @nseidle so he is aware. Do you think a MicroMod Global Tracker would be a good solution for you? This would allow you to select whichever processor is best for your needs. Artemis and ESP32 are both supported. It would look very similar to the MicroMod Asset Tracker. Understood about the buck-boost power circuit - and low quiescent current. We can certainly look at that. If you think of any more design requirements, please feel free to add them here. Thanks again, Paul

[jerabaul29]

I think a solution like this may be very attractive.

A few more things I can think about (though this is not essential for us at the moment, these may be nice to have later on, and would make the board even more attractive / versatile for us):

• having a SD card reader would be great

• I wonder if having a dedicated EEPROM chip connected to the Artemis (I know it is possible to emulate EEPROM in RAM, but not sure how this survives changing between sketches...) would be a nice addition (and how to make sure it can be switched on off to save power)

• also wonder if it would be possible to add an external RAM chip extension (340kB is a bit short for some of our applications; we would be much better out with 8MB, like https://www.pjrc.com/store/psram.html ). Also wonder how this can be make switchable on off for low power :) .

• regarding IMU etc: I have had a lot of issues with the BNO08x and getting it to work with the Artemis, and I have heard that there are issues with the ICM-20948 too ( @adamgarbo ). I have been experimenting lately with another approach as a consequence: using some "pure accel / gyro / mag measurement" breakouts, and doing the Kalman filtering on the Artemis. For example, I am using this breakout for now https://www.adafruit.com/product/4517 , though I will use this one when I can, as it has higher performance: https://www.adafruit.com/product/4569 . The thing is, it looks like there is a great library for doing the data fusion: https://github.com/adafruit/Adafruit_AHRS . I have been doing some tests, things work beautifully so far (see https://github.com/jerabaul29/Artemis_MbedOS_recipes/blob/main/recipes/recipe_LSM6DS0X_and_LIS3MDL_AHRS/recipe_LSM6DS0X_and_LIS3MDL_AHRS.ino , and in particular:

https://github.com/jerabaul29/Artemis_MbedOS_recipes/blob/9d72a4a785daf1f0ffc25268efb51182703d3490/recipes/recipe_LSM6DS0X_and_LIS3MDL_AHRS/recipe_LSM6DS0X_and_LIS3MDL_AHRS.ino#L165-L186

So I think that, if you want to integrate on the board the "best possible for medium price" equivalent (ie accel, gyro, magnetometer, if possible with "industrial" rating, like https://www.adafruit.com/product/4569 ), that may be a great idea. The advantages I see are: 1) it works well and is reliable 2) the user has full control, while there are libraries for doing all the work, 3) instead of using 15mA for an external chip with its own MCU, we can use a fraction of the Artemis MCU and pay virtually 0 cost in addition to the sensor itself (which is very low power, typically 1mA). Would be curious of what you think @adamgarbo :) . One thing about these 9-dof things: I wonder if they should be put on SPI instead of I2C for speed (from the observation that more of the Artemis is used for I2C communications than running the Kalman filter).

One more point: for me, a few dollars more or less is not a big deal, especially when there is an expensive component such as the Iridium modem. So, adding a few extras (buck-boost, SD, EEPROM, RAM, 9-dof measurements) at the cost of a bit of price increase is very attractive. From my employer the expensive thing is my working hours, so if I can cut on soldering time this is great :) .

[jerabaul29]

And having a few extra pressure buttons, a few extra user-controllable LEDs in different colors is nice too.

[jerabaul29]

And yet a couple more things:

• we are interested in using our electronics in the Arctic, so having components as capacitors etc that are all rated for -40 degrees C would be great ^^ :) . Mabye some people like deserts too, so +75 deg C rating too would be great :) .

• would also be great to be on the safe side regarding power supply to the iridium, i.e., would be happy to have the large supercaps per default (or at least possible to add as for the AGT :) ).

• a "nice to have but not essential" is that we like to have a simple way to "deploy" our instrumentation. The industry standard in my field is to have a reed switch: magnet on, the instrument is off (like, the battery is disconnected), and as soon as the magnet is removed, it turns on. I.e. the opposite of the https://www.sparkfun.com/products/10601 . For now, I am using something like this: https://no.mouser.com/ProductDetail/littelfuse/mdrr-dt-25-30-f/?qs=nyo4TFax6New9CGWZwJeTA%3D%3D&countrycode=NO&currencycode=NOK . Having such a reed switch between the battery and the "power in" rail, fixed on the very side of the board (so that it can be activated through the plastic wall of the box where we put it), as far as possible from the 9-dof stuff (so that we do not magnetize / influence it) would be great. For users who do not want to use this, maybe it would be possible to simply have a pad that can be soldered. But this is quite specialized, and I can add it myself too :) (and having magnets too close to the board raises problems of magnetization etc for the 9 dof stuff).

[jerabaul29]

One more thing: when there are some pads or similar that should be connected / disconnected (for example enabling disabling LEDs etc): would it be possible to get pads that are shorted by putting a bit of solder, rather than pads that are connected by a bit of PCB that needs to be cut? I find it much easier to put and remove solder than to cut PCB traces reliably.

[jerabaul29]

(regarding the RAM extension and EEPROM extension: some things like

https://www.adafruit.com/product/4719

and

https://www.sparkfun.com/products/14764 (can you get it with bigger capacity?)

would be great)

[jerabaul29]

PS: the FRAM is non volatile, so then could drop EEPROM altogether.

[adamgarbo]

Hi all,

To comment briefly, I would just say that I support many, if not all, of the suggestions @jerabaul29 has made.

@PaulZC, I believe a MicroMod product could be a good solution. In fact, I recently made a suggestion to @nseidle regarding an improved version of MicroMod Data Logging Carrier Board that could become the go to data logger for a wide range of scientific applications. Most importantly, I believe there's a business case that can be made for the development of this kind of product.

It would also be great to see many of the items @jerabaul29 has on his wishlist offered by À La Carte. The only reason I haven't started using this service is because of the lack of power regulation and control options.

Cheers, Adam

[jerabaul29]

Great to hear we have similar needs @adamgarbo :) .

I am really keen on these FRAM / MRAM btw, both here and as a separate SPI module (buying from Adafruit seems like the only option for now). If this could allow us to get rid of some SD cards here and there that would really be a blessing ^^ . I do not know how large capacity of MRAM chips can be sourced. But I guess many people need some stuff that is "either non volatile and / or larger capacity storage than S/D RAM", and "quite fast". I have been using SD cards for that a bit, but these are really a pain, would be much better to have anything between 4 and 16 MB of such storage.

[jerabaul29]

When we have this issue to give some feedback, one more poing @PaulZC :) :

I find the fact that there is a separate rechargeable battery for powering the "hot fix retention" of the GPS a bit unconvenient. This is yet another thing I must think about (I must remember to charge this little battery before deployment...), and it is unconvenient when having a large number of instruments to deploy (think 10 or 20 of them; I need a lot of USB-C outputs :) ). The result is that I have been dropping to charge this little battery several times (either because I did not have time, or I forgot, or it was too much headache). Also, not sure how long it will work; I understand it is not a problem for a balloon flight that had duration hours to days, but I would like to have instruments in the Arctic for a year or two of operations ultimately.

My "user wish" there would be to, rather than using this small battery, have the power input to the "hot fix retention pin" connected to the main power supply through the LDO or similar. The power draw is so low that I suppose it should not hurt the main battery... At the same time, the main battery is not disconnected once the instrument is being deployed, so this will always be powered on and the hotfix will be available. If you think that there are some use cases where this is detrimental, maybe having a couple of "solderable-pads" for selecting settings would be good?

[jerabaul29]

One extra thing I would like: a DIP switch in this kind: https://www.sparkfun.com/products/8034 . Maybe that could be a way to select such things as the hotfix saving mode and other "customizable" things such as enabling or disabling LEDs. It would also be great to have a few of the switches connected to some Artemis GPIO pins, so that they can be used to select instrument settings.

[jerabaul29]

Another thing: I use Reed magnetic switches as previously mentioned to turn the instruments on / off. Not sure if this has implication on "transient pulses" protection. Maybe a good idea to put a small caps bank on the input to protect against high transients?

[jerabaul29]

A couple more things. When / if there is a new board coming:

• could it be, as much as possible, a "superset" of the existing board, so that existing code can be used "as much as possible as is", i.e. ensure some form of backwards compatibility? :)

• any way the GPS module may be updated for something that is lower power? For example: https://www.u-blox.com/en/blogs/tech/u-blox-m10-ultra-low-power-gnss-small-high-performance-trackers-and-wearables .

[PaulZC]

Hi JR, Many thanks for all these contributions/suggestions - they are really useful. I can't promise if/when we'll be able to release AGT v2, but I will certainly try to include as many of your requests as possible! Thanks again, Paul

[jerabaul29]

Sounds amazing :) . If you build a v2, will be very interested in it :) .

[jerabaul29]

An extra thing I thought about now: for us in geosciences, it is much better to be able to use rechargeable LiFePO4 batteries than LiPo or LiIo batteries. The LiFePO4 seem to be much more robust to "bad treatment", too low / high temperatures, etc. So if the charge system could accomodate for either LiPo/Io (as of now), or LiFePO4 (new addition) by setting a setup pad or something like this, it would be amazing.

As it is now, I do not use the solar charger capability of the board, and I either use primary batteries instead, or use an external charger breakout, which is a bit painful.

[adamgarbo]

Don't forget the kitchen sink! 😉

[jerabaul29]

Small update: the very low number of pins broken out is really painful, hope we get some versions with more broken pins in the future :) .

[adamgarbo]

While I'm not actively using the AGT, I agree that access to more pins would be useful. I'm also currently dealing with this issue on the MicroMod Data Logging Carrier Board.

[PaulZC]

Don't forget that we offer Qwiic GPIO expansion boards. But thanks again for the feedback. Best wishes, Paul

[jerabaul29]

I agree about the Qwiic GPIO, but a bit sad to need one of these when the MCU actually has so many pins :) . Also, not as convenient because cannot source as much current from the pins etc I guess.

[a-schneider-fmi]

My wish list for the next version of the tracker is as follows (use case is meteorological balloons):

• A GPS that gives data above 12 km altitude.
• A more precise pressure sensor.
• Transmit pressure with more precision, at least in Pa instead of hPa (i.e. change in message format).
• 2 or 3 broken out GPIOs.

[PaulZC]

Hi Andreas (@a-schneider-fmi ), Thank you for the wish list! The ZOE-M8Q will work above 12km. The trick is to make sure you have the "Airborne <1g" dynamic platform model selected. The pressure sensor is a tricky one. The MS8607 is one of the few sensors which works at high altitude... Best wishes, Paul

[a-schneider-fmi]

Hi Paul (@PaulZC), Thank you very much for the hint with the dynamic model, that is good to know. I have updated the dynamic model setting to 6, and we will test it in our next balloon flight. Best wishes Andreas

[a-schneider-fmi]

Another feature that would be very handy for our use case is a temperature control, e.g. by switching on a heating if temperature drops below a threshold T1 and switching it off again if temperature rises above a threshold T2. This is to prevent the batteries and thus the device from stopping to work due to very low temperatures.

[adamgarbo]

Hi @a-schneider-fmi,

Would using batteries that are rated for cold temperatures not be a simpler solution? Heaters consume a significant amount of power.

For example, Energizer Lithium batteries are rated to -40°C (https://data.energizer.com/pdfs/l91.pdf) and Tadiran and Saft also make batteries specifically rated for extreme temperatures.

Cheers, Adam

[a-schneider-fmi]

In Arctic winter stratosphere with temperatures around -80°C we had failures with such batteries (I think it was Saft batteries if I recall correctly). After that we put heating to our devices. However, it would be better to regulate the heating with temperature measurements instead of heating all the time. It would be convenient if the tracker's temperature measurement can be used for that.

[adamgarbo]

Hi Andreas,

Very interesting use case. Would love to see photos of your design. Tadiran does make an extended temperature series of battery suitable to -100°C, but the nominal discharge current is far below what is required of Iridium transmissions. I hadn't realized your application was so extreme, so it definitely sounds like insulation and heating is the way to go.

Cheers, Adam

[a-schneider-fmi]

Hi Adam, Currently we are in the process of replacing our old tracking system with one based on the AGT. The open source architecture has many advantages, such as easy customization, possibility to implement custom firmware features, open protocols, etc. Our new design is not finalized yet. In a first version we want to connect a custom PCB to the AGT by I2C to operate cutters, heating, etc. Cheers Andreas

[a-schneider-fmi]

A feature that will probably be interesting for a wider range of users would be to support to call a user function when certain temperature values are exceeded, similar to alarms but with a user function instead of messages. We could then use this framework to implement our heating system, but it will be more flexible.

[jerabaul29]

@PaulZC just FYI, our "AGT-based product" starts to be quite well tested, the components we went for (that could be relevant to consider for an AGT v2, so listing with comments about what we went for why):

• AGT of course :)
• Qwiic Power switch (though this could be avoided with more pins broken out, in particular if some of the high power pins get broken out; but with few pins broken out, this was the easiest way to turn the 9-dof on / off)
• Adafruit high accuracy 9-dof; this works flawlessly in our experience, has really low noise levels, and is much more reliable than the various "IMUs" I got my hand on, and the Adafruit AHRS library for performing Kalman filtering is able to run on the Artemis in real time, so this is in practice all the benefits of an IMU, at the cost of a 9-dof, with higher reliability, and much lower power consumption since the 9-dof is quite power effective, and the Artemis is it too :) . We are using: https://www.adafruit.com/product/4569
• pololu 3.3V step up step down: https://www.pololu.com/product/2122 this way we do not need to worry too much if the battery voltage under "iridium communication load" drops a bit especially at low temperature; I am combining this with a supercap or two directly in parallel of the battery cells just for being on the safe side: Supercapacitor, 7.5 F, 5.4 V from AVX https://no.farnell.com/avx/scmt32d755srbb0/cap-7-5f-5-4v-20-super-cap-radial/dp/2856935

The main pain point we have left is the lack of pins broken out... So an "all the pins" version of the AGT (possibly with some 9-dof and 3.3V step up step down built in) would be amazing.

[jerabaul29]

As a side note, the motivation for putting the supercap directly parallel to the battery, and not on the AGT as is planned for now, is that this way the supercap can help other components than "just" the iridium modem, if we get some other components with high transient (actually, in really low temperature, the GPS falls under this "draw quite a bit and likes the help of the supercap" category). The leakage current of the supercap is around 70uA from the datasheet, which is low enough for our purpose.

[jerabaul29]

Also working on adding a '2 stage memory' to our project: a 4MB FRAM https://www.adafruit.com/product/4719 for being able to write fast / buffer data, and a SD card for being able now and then to write the contents of the FRAM to a larger non volatile memory. Think for us (and possibly everybody who need to log large amounts of data with low latency) this is a good fit :) .

[jerabaul29]

(note: if the Artemis line of products could be updated to Ambiq 4, the extra FRAM would become in necessary).