Requirements for AGT V2 #24
Comments
|
Hi JR (@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):
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 :) . |
|
And having a few extra pressure buttons, a few extra user-controllable LEDs in different colors is nice too. |
|
And yet a couple more things:
|
|
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. |
|
(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) |
|
PS: the FRAM is non volatile, so then could drop EEPROM altogether. |
|
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, |
|
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. |
|
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? |
|
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. |
|
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? |
|
A couple more things. When / if there is a new board coming:
|
|
Hi JR, |
PaulZC
changed the title
|
Sounds amazing :) . If you build a v2, will be very interested in it :) . |
|
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. |
|
Don't forget the kitchen sink! 😉 |
|
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 :) . |
|
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. |
|
Don't forget that we offer Qwiic GPIO expansion boards. But thanks again for the feedback. |
|
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. |
|
My wish list for the next version of the tracker is as follows (use case is meteorological balloons):
|
|
Hi Andreas (@a-schneider-fmi ), |
|
Hi Paul (@PaulZC), |
|
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. |
|
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, |
|
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. |
|
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, |
|
Hi Adam, |
|
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. |
|
@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):
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. |
|
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. |
|
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 :) . |
|
(note: if the Artemis line of products could be updated to Ambiq 4, the extra FRAM would become in necessary). |
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 :) .
The text was updated successfully, but these errors were encountered: