@Gijs you cant save strings with it.

About FFT, there is 'ulab' module (a micro NumPy/SciPy) for Pycom MicroPython, see the topic "Pycom firmwares with single/double precision and ulab module".

FYI: I made this https://github.com/somervda/lopybase repository for testing out deepsleep/lorawan etc on lopy4 - it seems to work for me . I also have a video that walks though some of the code here https://youtu.be/5pBcGdR8pR4 . It may be useful :)

@somervda The pull request linked in that issue is actually completely unrelated (it just has the same number so it got linked by mistake apparently). Not sure if that was ever actually fixed, one would have to dig into the sources to check. I was under the impression ADR ended up working with deep sleep at some point, but last time I tried it was ages ago and I don't quite remember the details.

@robert-hh I guess that's why it's pushing half a watt of RF & claiming -20dBm? Any idea where I could find out the best bandwidth/coding-rate/preamble values to use with sf=12 in raw mode?

Thanks - those clues did the trick. I now have almost instantaneous joining (1 or 2 trys) and 100% transmission reliability when local to my gateway. Below is the code I added to clear the channels and re-establish channels for TTN US915 . Note I also set "adr=True" when creating the lora object. [image: 1597335935089-fixed.jpg] I now am getting some decent ttnmapper results. Just under 1km , this is with a TTN indoor gateway and some hills and houses between me and the gateway. [image: 1597336208381-ttnmapper.jpg]

@kjm lora.stats returns a named tuple. The values are either obtained by indexing or by access to its elements, like: stats = lora.stats() print (stats.tx_power, "is the same as", stats[6])

Hi, As you see, the Lopy1 has 4MB of flash memory. All our newer products sport larger Flash memory as the firmware size is ever increasing with new features. The problem is that the files you are trying to upload will fill up the Flash to its maximum. You can either install one of the older (smaller) firmwares using the firmware updater tool, or do something with the mpy files. That is a pretty advanced procedure where you build your own firmware, there is some discussion around it in multiple places, I link one here: https://forum.pycom.io/topic/2686/requesting-manual-flashing-procedure/5?_=1597228804264

[2176354266] lorapf: INFO_ [main] Little endian host [2176354300] lorapf: INFO_ [main] lorawan_public 1, clksrc 1 lgw_board_setconf:584: Note: board configuration; lorawan_public:1, clksrc:1 [2176354301] lorapf: INFO_ [main] antenna_gain 0 dBi [2176354309] lorapf: INFO_ [main] Configuring TX LUT with 16 indexes [2176354312] lorapf: INFO_ [main] radio 0 enabled (type SX1257), center frequency 867500000, RSSI offset -164.000000, tx enabled 1 lgw_rxrf_setconf:618: Note: rf_chain 0 configuration; en:1 freq:867500000 rssi_offset:-164.000000 radio_type:2 tx_enable:1 [2176354334] lorapf: INFO_ [main] radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -164.000000, tx enabled 0 lgw_rxrf_setconf:618: Note: rf_chain 1 configuration; en:1 freq:868500000 rssi_offset:-164.000000 radio_type:2 tx_enable:0 [2176354357] lorapf: INFO_ [main] Lora multi-SF channel 0> radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12 lgw_rxif_setconf:737: Note: LoRa 'multi' if_chain 0 configuration; en:1 freq:-400000 SF_mask:0x7e [2176354375] lorapf: INFO_ [main] Lora multi-SF channel 1> radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12 lgw_rxif_setconf:737: Note: LoRa 'multi' if_chain 1 configuration; en:1 freq:-200000 SF_mask:0x7e [2176354392] lorapf: INFO_ [main] Lora multi-SF channel 2> radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12 lgw_rxif_setconf:737: Note: LoRa 'multi' if_chain 2 configuration; en:1 freq:0 SF_mask:0x7e [2176354409] lorapf: INFO_ [main] Lora multi-SF channel 3> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12 lgw_rxif_setconf:737: Note: LoRa 'multi' if_chain 3 configuration; en:1 freq:-400000 SF_mask:0x7e [2176354427] lorapf: INFO_ [main] Lora multi-SF channel 4> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12 lgw_rxif_setconf:737: Note: LoRa 'multi' if_chain 4 configuration; en:1 freq:-200000 SF_mask:0x7e [2176354445] lorapf: INFO_ [main] Lora multi-SF channel 5> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12 lgw_rxif_setconf:737: Note: LoRa 'multi' if_chain 5 configuration; en:1 freq:0 SF_mask:0x7e [2176354462] lorapf: INFO_ [main] Lora multi-SF channel 6> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12 lgw_rxif_setconf:737: Note: LoRa 'multi' if_chain 6 configuration; en:1 freq:200000 SF_mask:0x7e [2176354480] lorapf: INFO_ [main] Lora multi-SF channel 7> radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12 lgw_rxif_setconf:737: Note: LoRa 'multi' if_chain 7 configuration; en:1 freq:400000 SF_mask:0x7e [2176354498] lorapf: INFO_ [main] Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7 lgw_rxif_setconf:711: Note: LoRa 'std' if_chain 8 configuration; en:1 freq:-200000 bw:2 dr:2 [2176354514] lorapf: INFO_ [main] FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate lgw_rxif_setconf:767: Note: FSK if_chain 9 configuration; en:1 freq:300000 bw:3 dr:50000 (50000 real dr) sync:0xc194c1 [2176354570] lorapf: INFO_ [main] gateway MAC address is configured to 26AB27CD15DC19BA [2176354570] lorapf: INFO_ [main] server hostname or IP address is configured to "router.eu.thethings.network" [2176354577] lorapf: INFO_ [main] upstream port is configured to "1700" [2176354583] lorapf: INFO_ [main] downstream port is configured to "1700" [2176354589] lorapf: INFO_ [main] downstream keep-alive interval is configured to 10 seconds [2176354597] lorapf: INFO_ [main] statistics display interval is configured to 30 seconds [2176354605] lorapf: INFO_ [main] upstream PUSH_DATA time-out is configured to 100 ms [2176354613] lorapf: INFO_ [main] packets received with a valid CRC will be forwarded [2176354620] lorapf: INFO_ [main] packets received with a CRC error will NOT be forwarded [2176354628] lorapf: INFO_ [main] packets received with no CRC will NOT be forwarded [2176354639] lorapf: INFO_ [main] found global configuration file and parsed correctly lgw_calibrate_sx125x:503: Note: calibration started (time: 2300 ms) lgw_calibrate_sx125x:524: Note: calibration finished (status = 0xBF) lgw_calibrate_sx125x:561: calibration a_i = 27 lgw_calibrate_sx125x:561: calibration a_i = 21 lgw_calibrate_sx125x:561: calibration a_i = 17 lgw_calibrate_sx125x:561: calibration a_i = 15 lgw_calibrate_sx125x:561: calibration a_i = 11 lgw_calibrate_sx125x:561: calibration a_i = 9 lgw_calibrate_sx125x:561: calibration a_i = 7 lgw_calibrate_sx125x:561: calibration a_i = 6 lgw_calibrate_sx125x:503: Note: calibration started (time: 2300 ms) lgw_calibrate_sx125x:524: Note: calibration finished (status = 0xBF) lgw_calibrate_sx125x:561: calibration a_i = 14 lgw_calibrate_sx125x:561: calibration a_i = 11 lgw_calibrate_sx125x:561: calibration a_i = 9 lgw_calibrate_sx125x:561: calibration a_i = 7 lgw_calibrate_sx125x:561: calibration a_i = 5 lgw_calibrate_sx125x:561: calibration a_i = 4 lgw_calibrate_sx125x:561: calibration a_i = 3 lgw_calibrate_sx125x:561: calibration a_i = 3 Info: Initialising AGC firmware... Info: putting back original RADIO_SELECT value [2176361808] lorapf: INFO_ [main] concentrator started, packet can now be received [2176361809] lorapf: INFO_ [up ] start LoRa GW started [2176361810] lorapf: INFO_ [down] start [2176361811] lorapf: INFO_ [jit ] start [2176361812] lorapf: INFO_ [ts ] start [2176379962] lorapf: INFO_ [up ] received pkt from mote: D003268F (fcnt=46037/B3D5), RSSI -125.0 [2176380015] lorapf: WARN_ [up ] PUSH_ACK recieve timeout 0 [2176380065] lorapf: WARN_ [up ] PUSH_ACK recieve timeout 1 [2176384348] lorapf: INFO_ jitqueue: Current concentrator tv_sec=25 time_us=25206060, pkt_type=0, packet->count_us=25805347, (c-t)=599287/599287 us = 0/0 s [2176384351] lorapf: WARN_ jitqueue: IGNORED: not REJECTED, already too late to send it (current=25206060, packet=25805347, type=0) [2176391814] lorapf: INFO_ [main] report ##### 2020-07-24 16:47:38 GMT ##### ### [UPSTREAM] ### # RF packets received by concentrator: 1 # CRC_OK: 100.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00% # RF packets forwarded: 1 (23 bytes) # PUSH_DATA datagrams sent: 1 (206 bytes) # PUSH_DATA acknowledged: 0.00% ### [DOWNSTREAM] ### # PULL_DATA sent: 3 (66.67% acknowledged) # PULL_RESP(onse) datagrams received: 1 (208 bytes) # RF packets sent to concentrator: 1 (33 bytes) # TX errors: 0 # TX rejected (collision packet): 0.00% (req:1, rej:0) # TX rejected (collision beacon): 0.00% (req:1, rej:0) # TX rejected (too late): 0.00% (req:1, rej:0) # TX rejected (too early): 0.00% (req:1, rej:0) ### [JIT] ### [jit] queue is empty ### [GPS] ### # GPS sync is disabled ##### END ##### [2176391875] lorapf: WARN_ [up ] ignored out-of sync PUSH_ACK packet buff_ack[0:0] != token[0:1] [2176391930] lorapf: WARN_ [up ] PUSH_ACK recieve timeout 1 [2176421871] lorapf: INFO_ [main] report ##### 2020-07-24 16:48:08 GMT ##### ### [UPSTREAM] ### # RF packets received by concentrator: 0 # CRC_OK: 0.00%, CRC_FAIL: 0.00%, NO_CRC: 0.00% # RF packets forwarded: 0 (0 bytes) # PUSH_DATA datagrams sent: 1 (111 bytes) # PUSH_DATA acknowledged: 0.00% ### [DOWNSTREAM] ### # PULL_DATA sent: 3 (100.00% acknowledged) # PULL_RESP(onse) datagrams received: 0 (0 bytes) # RF packets sent to concentrator: 0 (0 bytes) # TX errors: 0 # TX rejected (collision packet): 0.00% (req:1, rej:0) # TX rejected (collision beacon): 0.00% (req:1, rej:0) # TX rejected (too late): 0.00% (req:1, rej:0) # TX rejected (too early): 0.00% (req:1, rej:0) ### [JIT] ### [jit] queue is empty ### [GPS] ### # GPS sync is disabled ##### END #####```

@Bhavit beware that in most regions there are limits on the use of the ISM band/sub-band chosen for LoRa, and you usually can’t send continuously (or you have to check that the channel is available before sending). The exact details vary a lot from region to region, though. Also throughput will of course vary a lot depending on the day rate (spreading factor/bandwidth). Some modulations are a lot faster than others (at the expense of range, in theory).

Which firmware version are you using? Pybytes or Pygate? Is pybytes activated on boot or no? Can you submit the whole stack trace (from power on reset to coredump and on)? Is your power supply maybe at fault here? Are you able to supply enough current? This basic example should work on any device without errors, so I am wondering what is different in your case..

@sheng Use to the 433MHz connector.

@robert-hh So if I'll program that node as Class C then is it possible that I can get better throughput ?

@robert-hh Thank you many times. It helps a lot.

@miwink Better use wavelength/2 antennas, even if they are larger. The first one @Eric73 linked or the pycom antenna are such. They are more forgiving in handling.

Hello, this is local regulation so it's better to check which law you have to follow. In europe we work with ETSI , it seem that TRAI is india regulator (Telecom Regulatory Authority of India) you nedd to check if some specification is available from them. According to LoraWAN regionnal settings, it's seem that you can use SF12 to SF7 with BW125 (not 250 or 500) with max power 20db without trouble, i dont know about other BW https://lora-alliance.org/sites/default/files/2018-05/lorawan_regional_parameters_v1.0.2_final_1944_1.pdf

@jg_spitfire We might refer to different code. tmst is the intended time for transmission. When a packet arrives, tmst must be larger than the actual value of ticks_cpu(). So t_us is the calculated as: t_us = tmst - utime.ticks_cpu() - 15000 That will be the time for the alarm handler, which then actually sends the downlink. The net time tmst - utime.ticks_cpu() is reduced by anther 15 ms to take in account the software needs for setting up the alarm and starting the scheduled function. In the change I suggested for analysis there was the first lines: t_us = utime.ticks_cpu() print("tmst = ", tmst, ", t_us = ", t_us) in that printout, indeed tmst > t_us is the good case. So you were right asking.