PyCom alternatives?



  • Hi! Since PyCom is potentially shutting down as a company, I have started looking for some alternatives. Ideally looking for devices that are already CE certified, have cellular capabilities, and doesn't require too much of changing to code written for PyComs (so, a device that runs MicroPython). Should also be capable of being battery-powered and support flash encryption. Any viable alternatives?



  • If you're interested in checking out Particle I can get you a sample!

    • LTE
    • Developer friendly ecosystem
    • Certified
    • Easy transition from pycom


  • This post is deleted!


  • @jcaron We have investigated moving the SIM card to the edge but there are two problems:

    • It cannot be placed at the ESP32 side because that would interfere the PCB antenna's RF view. This would violate Espressif's good practices and thus the CE/FCC certification of the ESP32-S3 module.
    • The only option left would be to choose the other side but there we have the USB-C connector which is through hole. Previous experiences have thought us that you do not want USB connectors to be purely SMD, sooner or later they will come loose and permanently damage the board.

    We therefore chose to place the SIM slot as close to the ESP32 as we could. It is a slide slot with hot plug SIM card support and I think we can easily solve the problem with a little 'tool' to push the card in/out even when Walter is soldered onto another PCB board.

    I will simulate this tomorrow and make a little video of the tests. Thank you for thinking along.



  • @Don-iot It would probably make sense to move it at least to the edge of the board, though depending on the type of card holder you may have to push it slightly over the edge (if it's a purely passive push-pull holder and the only way to take out the SIM would be to pull on it, as opposed to some kind of push-push holder where you can push on the SIM to have it come back out with a spring).



  • @Daan-Pape -I understand. We may be interested in the module you are developing if we will not move in another direction. Can we have a commercial discussion outside this forum to understand your timeline?



  • @Don-iot it is a size issue. When we would place the SIM card on top the module should be almost 20mm longer. This would break our goal to be GPy compatible as not all designs would be able to fit such a long module. Also it would interfere with RF from the antennas.

    You are right about it being very hard to replace the SIM card when the module is soldered. I'm open for suggestions on how to solve that. The only option that we were looking into was an eSIM SIM card.

    Kind regards,
    Daan



  • @Daan-Pape -Great to see the progress! I'm curious why the SIM has to be on the underside of the product; it is the only thing one needs to remove once the module is mounted on a board. If you solder the module in place, the SIM is impossible to get out. Personally it is the first thing from a Pycom module I would not have cloned.



  • @jcaron thanks for the tip, I didn't know it yet and I'm going to look into it with our team.



  • @Daan-Pape for JavaScript support low.js may be an alternative to Espruino.



  • @Tiit thanks for the feedback. We have kept physical pin compatibility but implemented the rest completely different. We have a physical modem reset, a switchable 3.3V output, the IO pins are 100% configurable and not shared with internal peripherals, ... Find out all about Walter on https://www.quickspot.io/



  • Hi all,

    It took some weeks longer than expected due to component lead times but I'm so glad to release Walter today. We have taken as much advice as we could and are convinced about the way we took. Get to know Walter on https://www.quickspot.io/

    Happy New Year!



  • @Daan-Pape Our company has a fleet of hundreds GPY units transmitting from fields for some years and of course we need a replacement and your proposal seems very good. But we think it's not needed to follow exactly the pinout and functionality of GPY - it was far from perfect. The new module should (flawlessly if possible) enclose all the modern possibilities of radio networks like software selection of NB or LTE-M, possible GPRS fallback, remote restart from network side, SMS control of field units, battery backed RTC, better ADC than ESP32 includes etc.
    We would be glad to contribute to new module development as we have some years of NB and LTE-M GPY experience with extensive sensor data.



  • Hi all,

    Just to let you know that we released the sneak peak of what we are doing on our socials: https://twitter.com/DPTechnics/status/1592873546036162568?s=20&t=qR8ZVm-3DsLylPHPmH3lQg



  • @jcaron @Daan-Pape I think that Monarch 2 is an option, it supports NB2, and that is crucial for next generation of mobile networks.



  • @Elizar our idea is to make a 100% compatible board but with improvements with lessons learned from the current GPy. Also we want to produce in Europe (Belgium and Netherlands) as we have our facilities here.



  • @SciWax we are aware of the problems with the current LTE implementation and in our design, which we hope to have ready soon, we have done some significant changes to fix the issues:

    • We will use the Monarch 2 platform, which holds some significant improvements.
    • We will add the possibility to hardware reset the modem using a spare GPIO pin.
    • The software will actively check the LTE connection

    This should fix all known issues.



  • @Don-iot I also would like a ping. :)



  • @jcaron I completely agree. One of the most annoying problems was, that the GPy sometimes thought, that the data connectivity through the modem was still given, while it was not in fact. In my current project, these events happen only a few times per year, but it is still annoying (Imagine having a fleet and you have to manually power cycle individual GPys....). Only a complete power cycle can fix it in my experience. For more information see this thread @Daan-Pape: https://forum.pycom.io/topic/6831/how-to-handle-a-lte-connectivity-loss?_=1667571587470

    Basically with the P-Ch-Mosfet I was able to fix the issue through another device. For normal resets of the GPy (because of Guru meditation errors), I use an Arduino board in my project.

    In regards how unstable the whole LTE-M feature thing worked with the GPy and Sequans modem, I have the same concerns. I need 2 additional pieces (Arduino board and P-CH-Mosfet) to make the LTE-M feature of the GPy work stable in the field. With these 2 additions, I've transmitted more than 95 % of my data to my database successfully in the field for 10 months. I was sending data every 5 minutes.

    Maybe lte-modems of U-Blox would be an alternative? I don't know personally.



  • @Elizar You could ask the administrator installed for Pycom. The address is at the Pycom web site.


Log in to reply
 

Pycom on Twitter