I'm trying to use nano-gateway with loraserver.io but I can not downstream messages just upstream. Can you share if you had the same problem?

@jmarcelino said in LoPy as a gateway send packet under TCP/IP: don’t recommend running TCP over LoRa itself. Sir, can you please elaborate more on how to change the lora packet data into tcp/ip format?

@robert-hh great thank you it worked perfectly!

@kots Even it that is true, it does not sound reasonable. G2 is used for the REPL communication. You might use another GPIO port for switching, but G2 seems to be an odd choice, as well as driving a step-up converter power input with a GPIO port, especially if a single transistor switch or digital gate is sufficient for the purpose.

Sorry to grave dig, but had I known this earlier it would have been helpful. This post is about the Decagon 5TM, which has two protocols, SDI-12 and DDI. The DDI is typical UART at 1200 baud, which you can read from any UART reader. I've tested it with an FTDI cable and know it works with a LoPy. You do however have to power cycle the sensor to get a new reading. Note: This may not work on new Decagon 5TM sensors if you have changed the SDI-12 address to anything other than 0. Factory default is 0. If you have not used SDI-12 to communicate with the sensor then it should work as expected. We used a mosfet to turn the power on and off for the sensor, controlled by GPIO. Reading the UART within 10s of milliseconds from turning the power on will give you your readings. Its all explained in the integration guide. http://publications.metergroup.com/Integration Guides/18237 5TM Integrators Guide.pdf I know this doesn't help with SDI-12, but jubbs is using the 5TM specifically, which has this dual protocol stack. The sensor was also just powered from 5 volts (same supply source as for the LoPy), the 5TM supports 3.6V-15V, check datasheet for more information including current draw.

hello, @robin said in Using a DHT11 with a LoPy works with old firmware version but not new firmware?: JurassicPork's library did not work for me. What code ? I have two branches in my library : master with the old method to collect the data . and pulses_get using the new function pulses_get Be careful in this branch the constructor has changed (see new examples) Friendly, J.P

@robert-hh That worked great. I'm now able to build the FW with our frozen bytecode. Next step is to figure out the OTA

Bump. Second vote for importing what's already in the mainline tree: https://github.com/micropython/micropython/blob/v1.9.4/ports/esp32/machine_touchpad.c (it must be quite a lot of work for Pycom to maintain their own fork of MicroPython.. not to mention how the MicroPython world is starting to get a bit fragmented with all the forks now)

@dan Well, don't understand why it is like that. Due to a research project I have had to "hack" the libraries to allow changing the transmission power. Should anyone need it, send me a PM (I have just programmed a "dirty" workaround so not even daring to push a change to github or something like that!)

@robert-hh Thank you, I forgot to limit the connections

I went through the update firmware process, and it can't even connect to the board at all. I'm pretty sure it's dead. Not sure if I killed it or it came bad, but it's got no signs of any life whatsoever.

I have no idea how LoRaWAN stack is implemented by PyCom. I just responded to your opening post that 155 bytes payload is not allowed with SF12 by the LoRaWAN Specification.

Hi, I just updated the firmware on the LoPy and PySense, following this guide: https://docs.pycom.io/chapter/gettingstarted/installation/firmwaretool.html Thanks

@bmarkus I found out that Thailand is using 920-950Mhz bands while The Thing Network Propose Cambodia to use AS923-925Mhz (AS2) so 915Mhz bands could be used.

@stroggo Never mind. Found it Visual Studio Code.

@daniel @bucknall Ping! This is the same issue as: https://github.com/pycom/pycom-micropython-sigfox/issues/68