@tholden To see some info about problems with ADC which @jmarcelino pointed here is the link to issue report https://github.com/espressif/esp-idf/issues/164 and also interesting https://github.com/espressif/arduino-esp32/issues/92

If you prefer a 3D model, that is also available, see links below. .stl: https://www.pycom.io/wp-content/uploads/2017/04/lopy.stlNew.zip .obj: https://www.pycom.io/wp-content/uploads/2017/06/sipy.obj_.mtl_.zip

@kots As @jmarcelino said, just call lora.nvram_save() before going to deep sleep, and lora.nvram_restore() after initialising LoRa but before sending your message.

@jmarcelino Thank you for your answer!

@bmarkus said in LoRaWAN default channel allocations: Maybe I'm wrong, I do not have a live US environment here, but what is the default LoPy US channel allocation? I'm not saying it is wrong, just how to get it? The LoPy US915 channel allocation comes from the same place as the EU 868 channel allocation, the official LoRaWAN Regional Parameters specification published by the LoRa Alliance "2.2.2 US902-928 Channel Frequencies The 915 MHz ISM Band shall be divided into the following channel plans. Upstream – 64 channels numbered 0 to 63 utilizing LoRa 125 kHz BW varying from DR0 to DR3, using coding rate 4/5, starting at 902.3 MHz and incrementing linearly by 200 kHz to 914.9 MHz Upstream – 8 channels numbered 64 to 71 utilizing LoRa 500 kHz BW at DR4 starting at 903.0 MHz and incrementing linearly by 1.6 MHz to 914.2 MHz" so you get: channel 0: 902300 kHz dr: 0-3 channel 1: 902500 kHz dr: 0-3 channel 2: 902700 kHz dr: 0-3 channel 3: 902900 kHz dr: 0-3 ... and so on until channel 71: channel 71: 914200 kHz dr: 4

@jmarcelino hi , yes! Was about reading one ultrasonic sensor. Problem was fixed by using two other pins for sensor connecting. First was P11 and P12 and i did move to P21 and P22. I can not explain why...but seems work.

@jcaron The code is using ABP so there is no actual join procedure, it's just assigning keys

@joeri How accurate does it need to be? You could store the time before entering deep sleep and then when the board comes back you'd know it's the stored value + your deep sleep time + small adjustment to account for boot-up (which on my tests is about 1.9s but you should check for yourself) That should quickly give you a good approximation. Of course on the Pytrack you can get then get the GPS time.

Thanks @ahaw021 I am still wrapping my mind around how to go from sensor/MQTT-->LoPy send via LoRa to a LoPy acting as a RAW LoRa Nano-Gateway/LoPy--> that then forwards the message over wifi on local network. LoPy/LoRa Node --> LoPy/LoRa NanoGateway (recieves and forwards via WiFi)-->LoPy/WiFi NanoGateway --> local network. I apologize that I have not been very clear in my posts. In the LoPy NanoGateway discussion "The nodes send messages to the Nano-Gateway for further processing, this might include sending the messages over WiFi to a server for example." I want to forward messages over WiFi. The MQTT example HERE uses WiFi to send client messages to the MQTT Broker. Each LoRa/LoPy node needs to send the data to the NanoGateway, the NanoGateway needs to send it to the MQTT Broker. I don't know if there is a simple programmatic way to assemble and send the messages/topics from the NanoGateway to the MQTT Broker. Ideally it would just publish topics/data based on the message payload from the LoPy node. However, this hard codes publishing topics in node code. In the LoPy RAW NanoGateway example HERE the node code the message payload (Sensor Data Here) could include sensor data that the NanoGateway would publish the topic to the MQTT broker. msg = "Sensor Data Here" pkg = struct.pack(_LORA_PKG_FORMAT % len(msg), DEVICE_ID, len(msg), msg) lora_sock.send(pkg) It seems like this would work, but I would like the message payload to be inclusive like msg = "client.publish("/sensors/sensor8/print(temp)")" pkg = struct.pack(_LORA_PKG_FORMAT % len(msg), DEVICE_ID, len(msg), msg) lora_sock.send(pkg) I am not sure of a proper syntax to send in the message payload for parsing and forwarding. Perhaps just the topic e.g. /sensors/sensor8/temp, print(temp) The NanoGateway would receive the message payload and publish the topic with something like: client.publish("/sensors/sensor8/temp", "72.3") This would hard code each LoRa/LoPy sensor node with its topics, which is not very flexible. And I think this is just on way, not sure how to forward a node subscribing back via LoRa from the NanoGateway. Has anyone done anything like this? Any feedback is appreciated.

@ledbelly2142 said in Analog CO2 Sensor for LoPy, can 5v pin power it?: @bmarkus The COZIR sensors look nice. Are they in the sub $100 range? First hit of Google search gives $109 USD https://www.co2meter.com/products/cozir-0-2-co2-sensor As an indication you can visit the webshop of ChipCAD, a Hungarian distributor https://shop.chipcad.hu/Welcome/Default.aspx?scenarioID=360&pid=1878 Prices are in HUF (Hungarian Forint), VAT not included. At the moment 1 USD = 262.6 HUF But it may vary by distributor, quantity, shipping conditions, custom, etc. and model. You can ask GSS to advice where to buy it, they are good.

@chumelnicu Still on my to-do list I'm afraid, but maybe try iotmaker's code? https://forum.pycom.io/topic/1453/i2c-sensor-with-wipy2/11

@bucknall @jcaron @jmarcelino Guys, mystery solved. It seems like I have already damaged the sender Pycom by sending packets before attaching the antenna to it (improper use...). Now I used another Pycom acting as the sender and there is <1% packet loss. Lesson learned the hard way. Always read all documentation before playing around with the board :/

Issue solved by doing a complete download of all sources then re-doing all steps again.

I spent a great deal of time getting this to work on a Mac: Power off the board and put the jumper on Install the FTDIUSBSerialDriver_v...dmg Run this in the terminal: kextstat -b com.FTDI.driver.FTDIUSBSerialDriver you may have to run it a few times to get an output like this: Index Refs Address Size Wired Name (Version) UUID <Linked Against> 91 0 0xffffff7f80e43000 0x7000 0x7000 com.FTDI.driver.FTDIUSBSerialDriver (2.4.2) E16D9540-AF63-36AD-94C4-B1164FBD6078 <90 42 5 4 3 1> After that, reboot your machine. Once up, run the Pycom Firmware Update again. This time you'll see another port eg. /dev/cu.usbserial-DQ00DQIT Select the serial port and click 'continue' This time it'll run the whole process to update your firmware.

@VladimirAkopyan there are a couple of expansion boards already which I think are enough for prototyping and even smaller units PySense PyTrack Given the pricing and the fact that the grove connectors while nice to have are not essential whats the value add? You can also use grove with pycom base boards you just need the grove to pin adapter The only thing left is a solar trickle charger but these shouldnt be too hard to get I think i know where you are coming from but just dont think there is an urgent need - maybe there is Andrei

@jmarcelino I've tweaked the LoRa configs in every way I can think of. I get the same results when using data rate 4. I suppose the next step would be to examine if the packet (header + payload) is being created correctly through socket.send() however I know of no way to do that at the uPython command level. Any suggestions of next steps?

Why would you want to run your device directly from a solar cell? You will need a much larger panel/ device and it will be extremely weather dependant. Stop torturing yourself and get a tiny solar charger and a lipo battery, and [image: IMG_0245-450x300.jpg] Plug this into the battery port of the board, and you are done!