My understanding is that is the case, however I cannot say until I deploy. I would be shocked if the Pycom GPy would be able to connect to LTE there (it uses Verizon band 13 and a different modem than Boron), but not the Boron. I’ll find out soon. I live 2+ hours away from deployment site.
Gladly, and thank you for the help. First of all, #1 I am in extreme need of sleep modes. This will allow me to use a separate MCU for the heavy duty real-time SD pulse logging work and use Boron’s power-efficient LTE connection for data transmission while not wasting the ~17-20ma of resting do-nothing current while not uploading.
Practically identical in significance to “sleeping quiescent current” for low-power applications is “how many seconds on wake to re-establish the connection”. Therefore, for Boron to be a real killer, I need it to #2 take advantage of the Cat M1 LTE PSM/EDRX modes (see here), enabling it to wake up and upload my minutely 132-byte binary packet hopefully in just 4 seconds or under, not your whole 10-15+ second reconnection deal. This would be absolutely game-changing and decrease power consumption enough to significantly simplify remote station power system design, in some cases for me perhaps completely removing the need for a solar panel/charging controller and allowing a single lead-acid battery run the whole winter. Minimizes cost and complexity across the board.
Third, #3, an Input Capture-based digital pulse frequency library exactly like Teensy’s FreqMeasureMulti library would be so helpful it would probably allow me to not even need any separate controller. With the RTOS running on 64Mhz Boron, I could use a ported FreqMeasureMulti library to sample pulses and a separate SD card writing thread to attain 100% 6-byte-pulse logging rate with zero dropped pulses at 1,200Hz, which is my threshold requirement. Doing regular ISR interrupts won’t cut it. The FreqMeasureMulti library on Teensy is a god-send but a little tricky to port given the low-level Input Capture MCU stuff. HOWEVER, it actually might not be that hard since it is already written for ARM Cortex M4 architecture common to Boron and Teensy boards (I haven’t even figured out how to import external libraries in WebIDE yet, let alone try to port this library).
Fourth, #4, a way to underclock/adjust the MCU clock speed (as in the Teensyduino platform) would be incredibly valuable for low-power applications like mine. After profiling my real-time SD pulse frequency logging Teensy 3.6 main MCU (also does blocking I2C sensor calls on separate thread), I discovered I will never in a million years need more than 24Mhz to sustain my 1,200Hz pulses to SD card (6-bytes each) with 0% loss rate. I need more than 8Mhz but 16Mhz suffices, and 24Mhz just to be safe. I am wasting power running the Boron at 64Mhz.
Those four things would make this already-excellent product an unbeatable game changer for me from which I would never depart. Having a built-in DMA SD card reader - and/or some form of accessible SPI flash for data logging - would also be incredibly useful. My buffered SD writes to the Teensy 3.6 DMA-enabled built-in SDIO SD card with optimized SDFatSDIO library take only a handful of milliseconds or less, whereas (though I haven’t yet tested) connecting an external SPI SD card to Boron will be at least an order of magnitude longer.
Thanks again for responding. What in my list above do you think will be possible?