@robert-hh Today we have done tests again with much better results. Putting the Fipy Gateway outside, we get connection up to 2 km in urban environment, discontinuously. We believe that the problem was because of the window glass, which has a sun protection filter, which is why we have read it, it reduces the distance a lot. Thank you very much for your help.

Just to make sure (shouldn't be the case here as it works with one of the antennas, but you never know...), have you double-checked the antenna is connected to the right port on the LoPy? The 868 MHz port has moved between the LoPy 1 and LoPy 4, so it's easy to be confused.

@jmarcelino said in Sigfox RC4 Freezing after 1 msg:

time.sleep(20)

Works like a charm. Thanks a lot.

The documentation is a bit misguiding here, it says :

"there must a minimum of a 20s delay after resetting to the default macro-channel. Our API takes care of this [...]

for i in range(1, 100): # send something s.send('Hello ' + str(i))

There will be a 20 second delay after every 2 packets"

In fact, there should be a delay added between 2 packets. Maybe a suggestion for modification of the doc.

Anyway, thanks a lot for correcting me !
All the best.

@robert-hh

Thats true, for core dumps all hope is lost without something externally logging because the fact that the core dump has happened means the esp32 has crashed so it cant be logging

@dariox Just curious, did you rename the FW file when you loaded it onto the sd card? By default the downloaded file is named 'FIPY_GPY_NB1_35351.dup', but you are calling it 'FIPY_NB1_35351.dup'. Of course, you may have simply renamed it ... the reason I ask is because the Usage example in the README.md does not match the default file name.

@don said in lora.join never completes on OTAA example:

I'll see if I can downgrade the LoPy to 1.17.3.b1
1.17.3b1 is the most recent revision of the Pycom firmware. So you just have to update to the latest version.

@seb Thanks!

@sympatron
Hello,

We have already included the urequests.py file in lib folder as well as changed the line 53 to
ai = usocket.getaddrinfo(host, port)

But still getting the below error with the same code which is shared previously.

Traceback (most recent call last):
File "<stdin>", line 47, in <module>
File "urequests.py", line 100, in request
File "urequests.py", line 58, in request
OSError: -1

Please reply as soon as possible. Your help will be appreciable.

@jmarcelino
Am getting the error at gateway side. Error message with line number is as below
Traceback (most recent call last):
File "<stdin>", line 47, in <module>
TypeError: unsupported types for add: 'str', 'bytes'

Gateway code is attached also node side code is attached. And also please let me know whether i have used correct method to send data to server in the gateway code, using below lines of code

response = urequests.get("http://localhost/ksn/server.php?data=" + msg)
response.close()

1_1523684617338_node.py 0_1523684617338_gateway.py

Hi @jmarcelino

Thanks for this fix -- I've just been looking at the code in this area because of a problem that I've had with the new 'region-aware' firmware not working when I've removed the channels and added them back for AU915. Basically the code will 'freeze' after the send. The changes in the commit you mentioned showed me the reason why!

But, from the code in the commit that you mentioned, I don't think that the last channel that you added - 63+subband, will be added. The code in the commit will rule out any channel where the dr_min is not 0.

I'm thinking that the freezing that I have been seeing is from LoRaMac.c::ScheduleTx() which has a while loop looking for a valid channel supporting the requested data rate. With no valid channels because of the bug fixed in your commit, ScheduleTx() will never terminate. With your commit, the channels should be added correctly again. Though I will have to make sure that channel 65 for me, has dr_min=0, instead of dr_min=4, because of the requirement for dr_min=0.

Looking forward to the next release!

Thanks,
Brian

@livius
Hello,

Thank you very much for your quick response, as am new to server and pycom, it would be great help if you could share the code from fipy side and server side with step by step procedure.

Thank You

@nazz Here click me (scrol down a little) you can see the pictures of testing lab where you can see the pins for these pads. This presents GPy which have different pads placement, but gives you an idea.

@Nazz

Will need to do the opposite of what you've done here, send from the RPi, recvieve on the FiPy (see here: https://docs.pycom.io/chapter/firmwareapi/pycom/machine/UART.html#uartreadnbytes), and then do what ever sending you require.

@mdk22
But you make some modifications?

@rskoniec
Thank You sir