SiPy hardware integration.
-
I've been working with SiPy modules for a little while, and I have some questions and comments.
They are generally a nice, well engineered product, but:For the moment, I'd like to move away from the Pycom expansion board and replace it with my bespoke board incorporating the sensors and actuators that I need, but stick with purchases of Pycom processor modules (the DIP style, not OEM) right now during this "pilot production" phase. The move to the Pycom OEM hardware on my board might come later.
When programming the device using a UART (such as the FTDI chip on the Expansion Board) is any special hardware needed, or just a plain connection to the 3.3V UART logic levels? Do any of the handshaking lines such as CTS and RTS need to be connected to control any resets or similar, or is two-wire TXD/RXD (plus power and ground) all you need?
An open schematic for the Expansion Board would be a good move IMHO. OK, sure, you want to keep the hardware design of your microcontroller/RF modules proprietary and closed. I can live with that as long as I have the integration information I need to build my system. But an open reference design for the Expansion Board makes it a lot easier for engineers who are integrating your modules into custom hardware - it should get you more sales of Pycom MCU modules, not less.
It would be really nice to not need to re-implement the whole battery charger circuit etc from scratch - and it would be nice to see unambiguously how the FTDI serial chip is wired and what serial lines are mandatory to successfully talk to the Pycom module and deploy code.
OK, sure. There are a couple of bugs in the hardware that cause the high deep-sleep current. I get it. It happens.
But sometimes it feels a little like I want to buy your product, but it feels hard. It feels difficult for me to use the SiPy (or LoPy or whichever) module the way I need to use it, and I wonder why I don't just build my own system from scratch starting with a bare ESP32 and CC1125 and open-source MicroPython.
I'm considering moving to Pycom OEM hardware modules in future, but at the moment I want to move to a "semi OEM" model, consisting of Pycom DIP modules (such as the SiPy, but not exclusively) with the Pycom module plugged in to my bespoke motherboard base that I have designed.
The SiPy product page promises us a system, using the SigFox radio, that draws 0.5 uA in standby. That's a property of the SiPy board itself, not a property of the expansion board, deep sleep shield, or PySense board or whatever. I'd like to be able to purchase the SiPy product and have a product that meets the marketed specifications.
The page that discusses the high quiescent current deep-sleep issue mentions that "We will redesign the WiPy 2.0, LoPy 1.0 and SiPy 1.0 over the next few months in order to remove this deep sleep issue whilst enhancing the product performance to include 4MBytes of RAM and 8 Mbytes of flash.", but how close is this to reality? Are we going to see SiPy modules shipping with the relevant hardware changes soon, or is it a year away?
I can't just buy one blob of Pycom proprietary hardware and firmware, and stack it on top another blob of proprietary hardware, and then buy the Deep Sleep Shield which is yet another blob added to the stack, just to get the deep-sleep power budget down to where it's expected to be. It's physically too bulky, among other factors.
I think having control of the VDD_SDIO power domain that powers the external flash memory when the device is in deep sleep mode is a really important function. Micro-power and sleep performance are crucial in wireless sensor networks or IoT systems, and even if you needed to sacrifice a GPIO pin it's worth sacrificing a GPIO pin. Similarly with the mode of the DC-DC regulator - moving it permanently to eco mode for low quiescent power draw sounds like a very good idea.
The ESP32 already incorporates an ultra-low-power internal coprocessor designed for exactly this reason, handling wake ups and deep-sleep micropower interrupts from external hardware. So adding the PIC10F322 on the add-on board really feels like an inelegant hack, because it's redundant. The ESP32 itself should already be equipped to natively meet this exact use case.
The schematic of the deep-sleep shield has been released, but the schematic is quite trivial really, it's hardly more than just a high side FET driven by the PIC10F322.
The PIC10F322 firmware is really the important part, and it would be really useful if it was released. This means I can use the same code on a bespoke base-board with the Pycom modules, add the power-switching PIC10F322 to the board, and get the micropower performance as advertised - from the Pycom modules I've already purchased and from others I'll purchase in future before hardware changes are pushed through the stock pipeline.
This doesn't undercut any sales of Pycom microcontroller modules - but it makes it much easier for users in such a position to buy and use your product.
Similarly, I'd really like mechanical CAD drawings of the Pycom modules and expansion board. It would really make it a lot easier when I'm designing a mounting case for these boards. Dimensions, mounting hole locations (for the Expansion Board etc) and clearance distances would be really valuable information. (Once again, it's about making it easy for people to use your product in their application, therefore making it easy for people to buy your product.)
-
Sorry, I misunderstood.
I can only tell you that the Pygate mounting hole spacing is the same as the Expansionboard 3.0's spacing. We provide that here: https://docs.pycom.io/gitbook/assets/specsheets/Pycom_002_Specsheets_Pygate_v1.pdf in section 12.
I will work on getting the Expansionboard spacing out there on its own page!
-
@Gijs I'm not to woried about a 3d file, I just need a PDF of pin spacing / mounting holes.
-
@TurkDangerCat said in SiPy hardware integration.:
where are the mechanical specs on the datasheet for the Expansion 3.0 board?
For the expansionboard 3.0, you can find them here: http://docs.pycom.io/gitbook/assets/Expansion_Board_3D.step
We are working on getting more 3D files out there!
-
@seb Hi, where are the mechanical specs on the datasheet for the Expansion 3.0 board?
-
@luke said in SiPy hardware integration.:
I've been working with SiPy modules for a little while, and I have some questions and comments.
They are generally a nice, well engineered product, but:For the moment, I'd like to move away from the Pycom expansion board and replace it with my bespoke board incorporating the sensors and actuators that I need, but stick with purchases of Pycom processor modules (the DIP style, not OEM) right now during this "pilot production" phase. The move to the Pycom OEM hardware on my board might come later.
When programming the device using a UART (such as the FTDI chip on the Expansion Board) is any special hardware needed, or just a plain connection to the 3.3V UART logic levels? Do any of the handshaking lines such as CTS and RTS need to be connected to control any resets or similar, or is two-wire TXD/RXD (plus power and ground) all you need?
An open schematic for the Expansion Board would be a good move IMHO. OK, sure, you want to keep the hardware design of your microcontroller/RF modules proprietary and closed. I can live with that as long as I have the integration information I need to build my system. But an open reference design for the Expansion Board makes it a lot easier for engineers who are integrating your modules into custom hardware - it should get you more sales of Pycom MCU modules, not less.
It would be really nice to not need to re-implement the whole battery charger circuit etc from scratch - and it would be nice to see unambiguously how the FTDI serial chip is wired and what serial lines are mandatory to successfully talk to the Pycom module and deploy code.
Please see here: https://github.com/wipy/wipy/tree/master/hardware/ExpansionBoard-v1.2
OK, sure. There are a couple of bugs in the hardware that cause the high deep-sleep current. I get it. It happens.
But sometimes it feels a little like I want to buy your product, but it feels hard. It feels difficult for me to use the SiPy (or LoPy or whichever) module the way I need to use it, and I wonder why I don't just build my own system from scratch starting with a bare ESP32 and CC1125 and open-source MicroPython.
I'm considering moving to Pycom OEM hardware modules in future, but at the moment I want to move to a "semi OEM" model, consisting of Pycom DIP modules (such as the SiPy, but not exclusively) with the Pycom module plugged in to my bespoke motherboard base that I have designed.
The SiPy product page promises us a system, using the SigFox radio, that draws 0.5 uA in standby. That's a property of the SiPy board itself, not a property of the expansion board, deep sleep shield, or PySense board or whatever. I'd like to be able to purchase the SiPy product and have a product that meets the marketed specifications.
The page that discusses the high quiescent current deep-sleep issue mentions that "We will redesign the WiPy 2.0, LoPy 1.0 and SiPy 1.0 over the next few months in order to remove this deep sleep issue whilst enhancing the product performance to include 4MBytes of RAM and 8 Mbytes of flash.", but how close is this to reality? Are we going to see SiPy modules shipping with the relevant hardware changes soon, or is it a year away?
Please see the LoPy for this, we opted to combine the LoPy and SiPy into one product line with the fixed deep sleep.
I can't just buy one blob of Pycom proprietary hardware and firmware, and stack it on top another blob of proprietary hardware, and then buy the Deep Sleep Shield which is yet another blob added to the stack, just to get the deep-sleep power budget down to where it's expected to be. It's physically too bulky, among other factors.
I think having control of the VDD_SDIO power domain that powers the external flash memory when the device is in deep sleep mode is a really important function. Micro-power and sleep performance are crucial in wireless sensor networks or IoT systems, and even if you needed to sacrifice a GPIO pin it's worth sacrificing a GPIO pin. Similarly with the mode of the DC-DC regulator - moving it permanently to eco mode for low quiescent power draw sounds like a very good idea.
The ESP32 already incorporates an ultra-low-power internal coprocessor designed for exactly this reason, handling wake ups and deep-sleep micropower interrupts from external hardware. So adding the PIC10F322 on the add-on board really feels like an inelegant hack, because it's redundant. The ESP32 itself should already be equipped to natively meet this exact use case.
We are planning to add support for programming the ULP co-processor from micropython so stay tuned for that. As for the PIC, this was necessary as it completely removes power from the pycom module as a work around for the deep sleep issue. Therefore the co-processor would not work in this scenario.
The schematic of the deep-sleep shield has been released, but the schematic is quite trivial really, it's hardly more than just a high side FET driven by the PIC10F322.
The PIC10F322 firmware is really the important part, and it would be really useful if it was released. This means I can use the same code on a bespoke base-board with the Pycom modules, add the power-switching PIC10F322 to the board, and get the micropower performance as advertised - from the Pycom modules I've already purchased and from others I'll purchase in future before hardware changes are pushed through the stock pipeline.
We are considering open-sourcing the firmware but at the moment there are no concrete plans around this.
This doesn't undercut any sales of Pycom microcontroller modules - but it makes it much easier for users in such a position to buy and use your product.
Similarly, I'd really like mechanical CAD drawings of the Pycom modules and expansion board. It would really make it a lot easier when I'm designing a mounting case for these boards. Dimensions, mounting hole locations (for the Expansion Board etc) and clearance distances would be really valuable information. (Once again, it's about making it easy for people to use your product in their application, therefore making it easy for people to buy your product.)
Please check the datasheets on the docs website, the mechanical specs of the modules are definitely there. We also have KiCAD footprints for all modules on github.
-
@luke The "new version of the SiPy" is the LoPy 4, which supports both LoRa and SigFox, and doesn't have the deep sleep issues of the SiPy and LoPy 1. It is already available.
