@abhishek2101 That's good. besides that, make yourself familiar with ftp (file transfer protocol), who's only purpose is to transfer files. That avoids any copying errros.

@rcolistete Maybe I misunderstood your question. The code I was referring to above is my own library that calls the 'built-in' machine.I2C micropython driver supplied in the LoPy firmware binary rev. 1.18.1.r1. Example: def __init__(self): self.i2c = I2C(0, mode=I2C.MASTER, pins=(sda, scl), baudrate=100000); magEnable = [0x10, 0x20, 0x00] self.i2c.writeto_mem(MAG_DEV_ADDR, MAG_CONFIG_REG_A, bytearray(magEnable));

@eric73 This seems to have solved my problem! Thanks!

Hi @dpalharini Does the board work when powered with USB? Try pulling P8 high, if you also want to use the SD card, use a 10k pull-up.

@bmarkus If you exceed duty cycle limitations in your region, it's mainly illegal...

That's exactly what I wanted to know. Thanks a lot @robert-hh

Replying because this shows up on a Google search for "Pycom wlan.channel". https://docs.pycom.io/firmwareapi/pycom/network/wlan#wlan-channel-channel wlan.channel([channel]) Get or set the channel (only applicable in AP mode). It returns (or sets) the channel to be used by the access point. (Used in either AP or STA_AP modes). If you're using Station+AP mode (STA_AP) I suggest you verify if wlan.channel() and the channel of the station you wish to connect to have the same channel, if they do not the access point channel will be changed (as the WLAN PHY in the ESP32 can only operate on one channel). In my use case, when a user elects to change the station the ESP32 is connected to, I warn the user that the access point will drop out if the channels do not match. I am using L01 (LoPy OEM), firmware: 1.19.0.b4 [50f84dd-dirty].

@lora Hi, lopy4 use sx1276 semtech radio that can only do fsk,gfsk,msk,gmsk,ook and lora modulation. So i suppose for using ASK you need an external modem and use UART RX/TX.

@pkilcoyne Hello, my two cents about reading your topics, Basically if two lora module have same center Freq, same SF, same SYNCWORD (0x34 for lorawan and 0x12 for private lora), same coding rate, same IQ (IQ is inverted for lorawan and not inverted for private lora usally) and same HeaderSetup (implicit or explicit) the RX/TX work. I dont see where with lopy how we can set header mode, so i suppose it's always explicit ? In ERA-LORA it seem to be the same think (cannot set header mode so may be alway set a explicit?). They use "group ID" term instead of SYNCWORD, and they don't speak about IQ (so it's be supposed to be alway inverted ?) I suggest you to try inverting IQ in Lopy for RX and TX, set group ID to 12xx in era lora , be careful on how you select frequency on both module and try...may be it's change something. *I dont speak about header CRC mode setup it's a little bit fuzzy how it work.

@eric73 Thank you so much! It worked! Also, it can scan and advertise at the same time.

hi @jdcrunchman, we open-sourced the openthread (small) port to Lora (still not 100% features suported). More interesting, you can already use all mesh commands from https://github.com/openthread/openthread/blob/master/src/cli/README.md So, you can start already with UDP sockets. I take this opportunity, to invite Mesh enthusiastics (firmware and networking engineers) to even join Pycom (some formal JD will follow), as we have good plans to open Mesh to masses. <later edit>: If interested, just drop me an email on support@pycom.io

@iotgeek Some time ago Pycom team said that is FCC rated as 2.2 dB. Also that is unclear that this same level is consistent in all antennas.

@jcaron With version 1.14.0.b1 I get 1.6 seconds.

@jcaron said in How can I set the bandwidth of the Lopy4 to 7.8 kHz to achieve the RF sensititvity of -148 dBm?: @bmarkus In Europe, one of the sub-bands allows 10% duty cycle. Also, IIRC if you do LBT-AFA (listen before talk, frequency agility), there's no duty-cycle limit (maybe not on all bands, too lazy to check). You are right, and also allowed RF power may vary on subbands. Still bitrate is very low.

@sslupsky AFAIK, the enable pin is not accessible.

@robert-hh So a remote raw lora receiver with a lot of nodes sending it is just inevitable that collisions happen? My current "solution" is to send and wait for it to send back an acknowledge, if not just wait a random period of time.

@jcaron The Rising HF RHF301, on the frequencies described here: https://account.thethingsnetwork.org/api/v2/frequency-plans/US_902_928 So, it looks like that's 903900000 904100000 904300000 904500000 904700000 904900000 905100000 905300000 all on 125 kHz bw.

@_grunf Did you figure it out?

@robert-hh said in TTN EU inconsistent to LoRAWan Spec: I just stumbled over an inconsistency between TTN EU and the LoRa WAN specification. For Downlink messages with DR < 4 TTN uses the RX2 window with DR=3 (SF9BW125) at 869,525 MHz and a power level of 27. This does deviate from the LoRa Spec in two aspects: a) I would expect that for a downlink message at first the RX1 window ist used, with the data rate and frequency matching the Uplink message. b) If the RX2 windows is used, DR0 = SF12BW125 should be used. That is what the PyCom devices expect for the RX2 window. The Pycom devices seem to implement the LoRAWAN spec. As a consequence, downlink messages for low data rates are lost. @bmarkus : How is the behavior in the loriot network? @robert-hh LORIOT EU868 settings are compliant to the LoRaWAN Regional Specification, see channel plan: [image: 1535355311417-918ed79a-4566-4454-a9be-ce3624589ddc-image.png]