Pygate does not receive after downlink

Gijs

Great you were able to make something work!

I'd still like you to submit a PR on our repo and we can take a look at it somewhere in the future, it allows for better tracking than leaving it here on the forum, and to give you credit where credit is due :). It might just be an undiscovered issue.

Thanks!

pauldeng

@Gijs

PR created at https://github.com/pycom/pycom-micropython-sigfox/pull/561

Thanks.

netskink

@pauldeng I have a problem where I noticed I also have errors where the pygate does not receive packets after transmit. I tried to update my firmware and now the device works but lora no longer works whatsoever. I'll try this and see if this fix works. It seems you are building your own version of the firmware code from git.

FWIW, here is where I reported the issue and my process for updating pygate and gpy. https://forum.pycom.io/topic/7238/pygate-gpy-and-lora-failures

netskink

@pauldeng I have this problem. I pulled the same revision of the code you did. At least I think I did. in the pycom-micropython-sigfox directory, I did $ git checkout a37510c092bcec00671c924accb97dcdfa2f4b5d then I made you changes.

diff --git a/esp32/pygate/concentrator/cmd_manager.c b/esp32/pygate/concentrator/cmd_manager.c
index dba7ce511..13b032934 100644
--- a/esp32/pygate/concentrator/cmd_manager.c
+++ b/esp32/pygate/concentrator/cmd_manager.c
@@ -324,7 +324,7 @@ int cmd_manager_DecodeCmd(uint8_t *BufFromHost) {
                 }
 
                 /* Switch off SX1308 correlators to reduce power consumption during transmit */
-                esp_lgw_reg_w(LGW_CLKHS_EN, 0);
+                //JFDesp_lgw_reg_w(LGW_CLKHS_EN, 0);
 
                 /* Send packet */
                 SX1308.txongoing = 1;
@@ -359,16 +359,16 @@ int cmd_manager_DecodeCmd(uint8_t *BufFromHost) {
                 }
 
                 /* reset Sx1308 */
-                sx1308_dig_reset();
+                //JFDsx1308_dig_reset();
 
                 /* Switch SX1308 correlators back on  */
                 esp_lgw_reg_w(LGW_CLKHS_EN, 1);
 
                 /* restart SX1308 */
-                x = esp_lgw_start();
-                if (x < 0) {
+                //JFDx = esp_lgw_start();
+                //JFDif (x < 0) {
                     //pc.printf("lgw_start() failed\n");
-                }
+                //JFD}
 
                 /* Send command answer */
                 BufToHost[0] = 'f';

Aftewards, I built the code with:

make BOARD=GPY clean
make BOARD=GPY TARGET=boot
make BOARD=GPY TARGET=app
make BOARD=GPY ESPSPEED=115200 ESPPORT=/dev/ttyACM0 flash

Afterwards, I use the atom IDE to upload the pygate example which has main.py and config.json for connecting the pygate/gpy combo to the things network (ttn).

Sadly line 25 of main.py now has an error with this line:

machine.callback(trigger = (machine.PYGATE_START_EVT | machine.PYGATE_STOP_EVT | machine.PYGATE_ERROR_EVT), handler=machine_cb)

It appears this version of the firmware does not have a machine.callback() routine.

Any advice is appreciated.

jcaron

@netskink I believe you need to specify VARIANT=PYGATE in your make options to build the Pygate version.

netskink

@jcaron Your response makes me extremely happy. Many thanks.

At the moment, I am building the pycome-micropython-sigfox git repo on tip of development branch. If I can get it to build and run with similar results as the stock version, I will resume with Deng's pull and patch. With your suggestion I am doing this now:

$ make BOARD=GPY VARIANT=PYGATE clean
$ make BOARD=GPY TARGET=app VARIANT=PYGATE
$ make BOARD=GPY TARGET=boot VARIANT=PYGATE
$ make VARIANT=PYGATE BOARD=GPY ESPSPEED=115200 ESPPORT=/dev/ttyACM0 flash

This indeed builds and flashes the GPY in the PYGATE expansion board. As for results, when I see the GPY/PYGATE console, I see that it appears to run normally as with the stock image. I don't see it failing with "concentrator" message. However, I don't see messages from the node being relayed through the GPY/PYGATE to TTN. As far as the node is concerned, it delivered a loraWAN message though.

##### 2021-09-01 15:31:43 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 #####
[2717698799] LORAPF_WARN_:[up  ] ignored out-of sync PUSH_ACK packet buff_ack[0:38] != token[0:39]
[2717698851] LORAPF_WARN_:[up  ] PUSH_ACK recieve timeout 1

hmm. afterwards I noticed it reconnected to wifi then these are in message log:

2717771645] LORAPF_INFO_:[main] report
##### 2021-09-01 15:32:56 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 1
# CRC_OK: 0.00%, CRC_FAIL: 100.00%, NO_CRC: 0.00%
# RF packets forwarded: 0 (0 bytes)
# PUSH_DATA datagrams sent: 0 (0 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
### [JIT] ###
[jit] queue is empty
### [GPS] ###
# GPS sync is disabled
##### END #####
[2717771754] LORAPF_WARN_:[up  ] PUSH_ACK recieve timeout 0
[2717788687] LORAPF_INFO_:[up  ] received pkt from mote: 26022F3F (fcnt=43163/A89B), RSSI -101.0
[2717788740] LORAPF_WARN_:[up  ] PUSH_ACK recieve timeout 0
[2717789107] LORAPF_INFO_:jitqueue: Current concentrator tv_sec=50 time_us=50139381, pkt_type=0, packet->count_us=50670067, (c-t)=530686/530686 us = 0/0 s
[2717801684] LORAPF_INFO_:[main] report
##### 2021-09-01 15:33:26 GMT #####
### [UPSTREAM] ###
# RF packets received by concentrator: 3
# CRC_OK: 33.33%, CRC_FAIL: 66.67%, NO_CRC: 0.00%
# RF packets forwarded: 1 (22 bytes)
# PUSH_DATA datagrams sent: 2 (316 bytes)
# PUSH_DATA acknowledged: 100.00%
### [DOWNSTREAM] ###
# PULL_DATA sent: 3 (100.00% acknowledged)
# PULL_RESP(onse) datagrams received: 1 (180 bytes)
# RF packets sent to concentrator: 1 (12 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 #####
[2717801802] LORAPF_WARN_:[up  ] PUSH_ACK recieve timeout 0

However, the end result is still no message uploaded to TTN.

netskink

@jcaron I tried to reply here in the forums, but my post was flagged as spam. Here is the reply now in the issue section of the github.
https://github.com/pycom/pycom-micropython-sigfox/issues/563

Its really frustrating to try and use these forums and the forums work against you.

robert-hh

Its really frustrating to try and use these forums and the forums work against you.

It may be easier now. I added a few reputation points to your account.

netskink

@robert-hh said in Pygate does not receive after downlink:

Its really frustrating to try and use these forums and the forums work against you.

It may be easier now. I added a few reputation points to your account.

Thanks.

Carlton flores 2

any update on the issue ? its resolved now ?

Carlton flores 2

yeah you can check debug logs.. .

Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

Pygate does not receive after downlink

Pycom on Twitter