Expansion Board Suggestions
-
Hi, wonderful Pycom folk!
Ive been working with the various expansion boards (PySense, PyTrack, expansion 2.0) and keeping notes in my head and thought I'd share them with you in the hopes that you'll at least consider them for current and future revisions of the various expansion boards you offer. Here goes:All Boards
- Block diagrams: I see that pinouts are provided, but it would be nice to know how things are connected together via block diagram. For instance, on the PyTrack, is the UART output on the L76 accessible?
- Integrated battery gas gauge: it's really cool we can connect batteries to these devices correctly and that a pin is provided for ADC measurements of the battery. From my understanding, the battery charging function uses the TI BQ24040. Why not complete the offering and add a battery gas gauge? Correctly determining remaining battery capacity via the ADC is almost rocket science. There's chips out there that do a pretty good job and aren't too expensive. TI makes a companion chip for the BQ24040. That one is good, but this one is even better: https://www.maximintegrated.com/en/products/power/battery-management/MAX17048.html because of it's outstanding power usage.
- Integrated power source selection switch: would be nice to have a switch that allows for following states:
- USB power + battery charge
- battery-only
- USB power with no battery charge.
The reason for battery-only is simple: I want to be able to use the USB console while directly connected, but be on battery-only for testing purposes. There's also times when I want to leave the battery connected, but not be charging it (or discharging it if USB power is disconnected)
PyTrack
- Would be nice to have a U.fl port for external active/passive antenna
- Different GPS chip, please. The current one is rather inferior. I personally would prefer something from U-Blox in the M8 series, like the ZOE-M8B. It's a good alternative because it's built for low-power applications, small form-factor, and already has LNA built-in. Bonus just for me: it has a binary protocol. Don't have to waste CPU cycles buffering and decoding NMEA sentences. Shouldn't be too difficult to incorporate their C library into firmware image and build MP bindings.
That's about all I can think of right now. Hopefully some of these things are useful.
Thanks!
-
@brotherdust any chance you share the pin pad mapping on the bottom (at least RX/TX) ?
-
May be too late but for future
please expose 3 more pads so we can use then to solder other battery connector (even with wire)-
VBat
-
GND (we have plenty so not mandatory)
-
TS pin of the battery charger, my battery have NTC on then (3 pins), charger IC can manage it but can't use this feature just because the pin is not exposed on PCB.
-
Place a PTH resistor footprint to change charging current so we can set it to another value
-
Another user button would be fine ;-)
-
-
@gregcope said in Expansion Board Suggestions:
-
Its well known so lots of working examples
-
Has an LNA i believe so should have better reception
-
The one i have is much faster to fix, althought this could be antenna related
Yup, the ublox is fantastic. I originally purchased a quectel to have the GPS type as the one Pycom uses as I thought this would make integration much easier and found nothing but issues with it. I purchased a ublox later and found it much more of a polished product. I had both units next to each other on the same breadboard, powered from the same FiPy and the ublox, without fail, would get a fix before the quectel. Sometimes the difference was 10-15 seconds (ublox) vs 15 minutes (quectel). From testing it seems the quectel don't actually save their ephemeris data completely like they claim.
But the huge benefit I found from the ublox is their propriety protocol which is much cleaner and efficient than parsing NMEA strings and I can poll rather than reading a stream!! So in one poll command/response I can get Lat/Lon, full date and time, velocity, direction and accuracy/error. To do the same parsing NMEA strings takes at least 3 different string types. Also since I am reading a single response that I can parse I don't need to use the minigps library which again saves a huge amount of memory.
-
-
-
Its well known so lots of working examples
-
Has an LNA i believe so should have better reception
-
The one i have is much faster to fix, althought this could be antenna related
-
-
@gregcope said in Expansion Board Suggestions:
+1 to a different GNS chip Neo8 a good choice
Can you explain why? Power consumtion? Faster syncs? Cool features like events for geo fencing?
+1 for a plug to connect an external GPS-Antenna.
-
@brotherdust
+1 to a u.fl
+1 to switchable inputs
+1 to a different GNS chip Neo8 a good choice
-
If I can add to pytrack features
- gyroscope and compass (very much needed :-) )
- Integrated battery gas gauge
-
@jcaron said in Expansion Board Suggestions:
- why is the JST battery connector on the side, next to the USB port?
I don't like the JST connector. I have not found huge one cell LiPos with this plug in my local electronic store. Some additional solder points will be fine.
-
@jcaron RE: cases, I wonder if the right solution for you would be to use a 3d-printer or outsource it to someone who can print it for you. The geometry of such a case would be simple. You'd need to specify UV-stabilized plastic if your application is outdoor. Hopefully that helps.
-
@seb said in Expansion Board Suggestions:
Hi,
Once again thanks for the feedback, so here is what I was able to distil from your message
- Block diagrams for all expansion boards - This is certainly something we can add, and will be added to our todo list for the documentation refresh.
- Example code - I agree there is a lot of room for improvement here especially around the pytrack/pysense. Once the getting started section of the documentation has been update, checking/fixing/improving all of our examples will be my next task.
- UART & 1PPS pins - I have passed this on to the hardware team, if there is a new hardware revision of the Pytrack they will consider this
Thanks for wading through my rant and finding the key points. Yes, you've got it right. =) All the previous suggestions still apply, though!
-
If we are on the topic of what should be changed in future revisions of the expansion boards...
-
why is the JST battery connector on the side, next to the USB port? If you have a battery connected there, that makes the USB connector impractical in a case. Actually, it would probably be even better if the USB connector was “sticking out” a bit more so it could get through a case wall.
It also makes it impractical to disconnect/reconnect the battery while in a case. Having the connector on the other side (on the “right” if you have the USB connector “up”), or vertical rather than horizontal would probably be a lot more useful
-
the screw holes on the Pysense are partially covered by the module, which prevents mouting “from the top” in case you have a battery underneath.
-
adding a power input other than the USB port (but which can still be used to charge the battery) could be useful.
-
I believe there’s quite some demand for a board that would include the necessary hardware to connect a solar panel and a battery
-
a board that includes the usb + battery connectors (+possibly solar panel connector), a button and just a few I/O pins, but with a smaller form factor than the expansion board would probably be much appreciated.
-
having compatible cases, or pointers to existing cases with compatible screw holes / PCB guides would be quite useful. This is quite a complex quest in my experience (but if someone has suggestions for a case which would be practical for Pysense + LoPy + battery + a PIR sensor, please let me know!).
-
-
I would love a Tilt and Vibration Sensor to wake up device from deep sleep when moved, like
https://signalquest.com/product/components/sq-sen-200/
or similar. I'm using it in low power LoRa trackers and love it.
-
Hi,
Once again thanks for the feedback, so here is what I was able to distil from your message
- Block diagrams for all expansion boards - This is certainly something we can add, and will be added to our todo list for the documentation refresh.
- Example code - I agree there is a lot of room for improvement here especially around the pytrack/pysense. Once the getting started section of the documentation has been update, checking/fixing/improving all of our examples will be my next task.
- UART & 1PPS pins - I have passed this on to the hardware team, if there is a new hardware revision of the Pytrack they will consider this
-
@seb Thank you.
/begin rant (you have been warned!)
I hope that they'll take my suggestions seriously, especially around the block diagrams. I've noticed around the board that there has been several requests for them; requests that seem to be ignored. Speaking for myself, I'm very frustrated with this situation. Publishing block diagrams should be a basic requirement when releasing a product like this in the "maker space". I certainly appreciate how much example code has been published, but a lot of it is incomplete and some of it is broken. That's OK, because it's example code. But, in case anyone was wondering, I suspect the reason you don't get more pull requests helping with the example code is because there isn't enough information to work around the problem ourselves (not without playing tone-the-0.1mm-pin).As it stands, I can't use these boards in my projects. For example: PyTrack. It just astounds me that no one thought that making the UART and 1PPS pins accessible would be useful! Useful how? Well, I can use 1PPS pin for IRQ instead of having to lock up my I2C bus with read requests trying to figure out if any NMEA data is there, then having to reconstruct the sentences using regular expressions and a mess of buffers (see example code for L76 GPS). Result is less code and more power savings. Could use the UART pins for firmware updates, EPO files (see http://www.quectel.com/UploadImage/Downlad/Quectel_GNSS_Flash_EPO_Application_Note_V1.0.pdf), etc.
How much more would it have cost to put a couple more holes and traces in? I finally managed to find the test pads for UART RX/TX on the bottom of the board; so, there's that. Alas, my rant must end here. Hopefully someone out there will hear me. =) Thanks for listening.
/end rant
-
Hi,
Thanks for your great feedback, I have passed your notes onto the rest of the team!
