RAK2247_usb fails test_loragw_reg and no packets decoded

Issue:No receive packets or frames running lora_pkt_fwd

Setup:OS Lubuntu 20.04LTS x86_64 Hardware DN2800MT Intel single board, RAK2247_USB connected by USB cable to USB carrier board (not RAK). Also an end node Adafruit 32U4FRD95 that has joined successfully to other hot spots, 20 meters separate making join requests every minute

Server:Helium miner local running local in docker UDP port 1680

Details:Following https://doc.rakwireless.com/quick-start/rak2247-lorawan-gateway-concentrator-module/rak2247-to-x86-linux-pc-interface setup.
Executing
sudo tcpdump -i lo udp port 1680 -vv -X

12:48:04.023345 IP (tos 0x0, ttl 64, id 30276, offset 0, flags [DF], proto UDP (17), length 141)
localhost.44412 > localhost.1680: [bad udp cksum 0xfe8c -> 0x447f!] UDP, length 113
0x0000: 4500 008d 7644 4000 4011 c619 7f00 0001 E…vD@.@…
0x0010: 7f00 0001 ad7c 0690 0079 fe8c 0227 4500 …|…y…‘E.
0x0020: adad adad adad adad 7b22 7374 6174 223a …{“stat”:
0x0030: 7b22 7469 6d65 223a 2232 3032 302d 3038 {“time”:"2020-08
0x0040: 2d33 3020 3136 3a34 383a 3034 2047 4d54 -30.16:48:04.GMT
0x0050: 222c 2272 786e 6222 3a30 2c22 7278 6f6b ",“rxnb”:0,"rxok
0x0060: 223a 302c 2272 7866 7722 3a30 2c22 6163 ":0,“rxfw”:0,“ac
0x0070: 6b72 223a 3130 302e 302c 2264 776e 6222 kr”:100.0,“dwnb”
0x0080: 3a30 2c22 7478 6e62 223a 307d 7d :0,“txnb”:0}}
12:48:04.026794 IP (tos 0x0, ttl 64, id 30277, offset 0, flags [DF], proto UDP (17), length 32)
localhost.1680 > localhost.44412: [bad udp cksum 0xfe1f -> 0x069f!] UDP, length 4
0x0000: 4500 0020 7645 4000 4011 c685 7f00 0001 E…vE@.@…
0x0010: 7f00 0001 0690 ad7c 000c fe1f 0227 4501 …|…‘E.
12:48:05.566331 IP (tos 0x0, ttl 64, id 30556, offset 0, flags [DF], proto UDP (17), length 40)
localhost.48489 > localhost.1680: [bad udp cksum 0xfe27 -> 0xaefc!] UDP, length 12
0x0000: 4500 0028 775c 4000 4011 c566 7f00 0001 E…(w@.@…f…
0x0010: 7f00 0001 bd69 0690 0014 fe27 0214 d602 …i…’…
0x0020: adad adad adad adad …
12:48:05.569702 IP (tos 0x0, ttl 64, id 30557, offset 0, flags [DF], proto UDP (17), length 32)
localhost.1680 > localhost.48489: [bad udp cksum 0xfe1f -> 0x65c1!] UDP, length 4
0x0000: 4500 0020 775d 4000 4011 c56d 7f00 0001 E…w]@.@…m…
0x0010: 7f00 0001 0690 bd69 000c fe1f 0214 d604 …i…
12:48:15.570263 IP (tos 0x0, ttl 64, id 32585, offset 0, flags [DF], proto UDP (17), length 40)
localhost.48489 > localhost.1680: [bad udp cksum 0xfe27 -> 0x1ddf!] UDP, length 12
0x0000: 4500 0028 7f49 4000 4011 bd79 7f00 0001 E…(.I@.@…y…
0x0010: 7f00 0001 bd69 0690 0014 fe27 0232 6702 …i…’.2g.
0x0020: adad adad adad adad …
12:48:15.572667 IP (tos 0x0, ttl 64, id 32586, offset 0, flags [DF], proto UDP (17), length 32)
localhost.1680 > localhost.48489: [bad udp cksum 0xfe1f -> 0xd4a3!] UDP, length 4
0x0000: 4500 0020 7f4a 4000 4011 bd80 7f00 0001 E…J@.@…
0x0010: 7f00 0001 0690 bd69 000c fe1f 0232 6704 …i…2g.

After stopping it with
sudo systemctl stop ttn-gateway
and executing
cd rak_common_for_gateway/lora/rak2247_usb/lora_gateway/libloragw/
sudo ./test_loragw_reg | grep MIS -

###MISMATCH### reg number 8 read: 236 (ec) default: 0 (0)
###MISMATCH### reg number 10 read: 138 (8a) default: 0 (0)
###MISMATCH### reg number 285 read: 224 (e0) default: 0 (0)
###MISMATCH### reg number 298 read: 7 (7) default: 0 (0)

After changing loragw_spi.native.c to:
#define SPI_SPEED 1000000
and recompiling same results.
All four tests of test_loragw_spi run succefully.

sudo ./test_loragw_cal --a 904.700 -b 905.000 -r 1257 -n 1

sudo ./test_loragw_cal -a 904.700 -b 905.000 -r 1257 -n 1
Library version information: Version: 5.0.1;
Radio type: 2
Radio A frequency: 904.700000 MHz
Radio B frequency: 905.000000 MHz
Number of calibration iterations: 1
Calibration command: brd: 0, chip: 1257, dac: 3

WARNING: problem in calibration of radio A for image rejection
Rx A IQ mismatch: Amp: -4 Phi: 19 Rej: 47 dB Status: 135 | Debug: Rej: 45 dB Lna: 1 BB: 15 Dec: 7

Rx B IQ mismatch: Amp: -3 Phi: 6 Rej: 57 dB Status: 151 | Debug: Rej: 55 dB Lna: 1 BB: 15 Dec: 7

Tx A calibration bypassed

Tx B calibration bypassed

Rx A IQ mismatch calibration statistics on 1 iterations (min, max):
Amp: -4 -4 Phi: 19 19 Rej: 47 47 dB (capt.: 45 45 dB)

Rx B IQ mismatch calibration statistics on 1 iterations (min, max):
Amp: -3 -3 Phi: 6 6 Rej: 57 57 dB (capt.: 55 55 dB)

End of radio calibration test

I think I need a replacement but I’m willing to keep working at it : )

And more info from dmesg
[ 13.140406] usbcore: registered new interface driver usbserial_generic
[ 13.140452] usbserial: USB Serial support registered for generic
[ 13.169599] usbcore: registered new interface driver ftdi_sio
[ 13.169648] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 13.169887] ftdi_sio 1-3:1.0: FTDI USB Serial Device converter detected
[ 13.170018] usb 1-3: Detected FT2232H
[ 13.188036] usb 1-3: FTDI USB Serial Device converter now attached to ttyUSB0
[ 13.192062] ftdi_sio 1-3:1.1: FTDI USB Serial Device converter detected
[ 13.192201] usb 1-3: Detected FT2232H
[ 13.198825] usb 1-3: FTDI USB Serial Device converter now attached to ttyUSB1

Also I use the US global_conf.json from Helium to get us freq.
Also output from directly starting
lora_pkt_fwd to show frequencies in use

*** Beacon Packet Forwarder for Lora Gateway ***
Version: 4.0.1
*** Lora concentrator HAL library version info ***
Version: 5.0.1;


INFO: Little endian host
INFO: found global configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters### [JIT] ###

SX1301 time (PPS): 2488222

src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty

[GPS]

Invalid time reference (age: 1598830789 sec)

no valid GPS coordinates available yet

END

JSON up: {“stat”:{“time”:“2020-08-30 23:39:49 GMT”,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0}}
INFO: [up] PUSH_ACK received in 2 ms
INFO: [down] PULL_ACK received in 0 ms
INFO: [down] PULL_ACK received in 2 ms
INFO: [down] PULL_ACK received in 0 ms

2020-08-30 23:40:19 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: 100.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

BEACON queued: 0

BEACON sent so far: 0

BEACON rejected: 0

INFO: lorawan_public 1, clksrc 1
INFO: no configuration for LBT
INFO: antenna_gain 0 dBi
INFO: Configuring TX LUT with 16 indexes
INFO: radio 0 enabled (type SX1257), center frequency 904300000, RSSI offset -166.000000, tx enabled 1, tx_notch_freq 0
INFO: radio 1 enabled (type SX1257), center frequency 905000000, RSSI offset -166.000000, tx enabled 0, tx_notch_freq 0
INFO: Lora multi-SF channel 0> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 1> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 2> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 3> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 4> radio 1, IF -300000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 5> radio 1, IF -100000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 6> radio 1, IF 100000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 7> radio 1, IF 300000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora std channel> radio 0, IF 300000 Hz, 500000 Hz bw, SF 8
INFO: FSK channel 8 disabled
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to ADADADADADADADAD
INFO: server hostname or IP address is configured to “localhost”
INFO: upstream port is configured to “1680”
INFO: downstream port is configured to “1680”
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: GPS serial port path is configured to “/dev/ttyS0”
INFO: found local configuration file local_conf.json, parsing it
INFO: redefined parameters will overwrite global parameters
INFO: local_conf.json does not contain a JSON object named SX1301_conf
INFO: local_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to ADADADADADADADAD
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: [main] TTY port /dev/ttyS0 open for GPS synchronization
global_conf.jsonINFO: [main] concentrator started, packet can now be received
INFO: [down] PULL_ACK received in 2 ms

INFO: Disabling GPS mode for concentrator’s counter…
INFO: host/sx1301 time offset=(1598830756s:704605µs) - drift=1598830756704605µs
INFO: Enabling GPS mode for concentrator’s counter.

INFO: [down] PULL_ACK received in 0 ms
INFO: [down] PULL_ACK received in 1 ms

2020-08-30 23:39:49 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: 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

BEACON queued: 0

BEACON sent so far: 0

BEACON rejected: 0

[JIT]

SX1301 time (PPS): 2488222

src/jitqueue.c:448:jit_print_queue(): INFO: [jit] queue is empty

[GPS]

Invalid time reference (age: 1598830789 sec)

no valid GPS coordinates available yet

END

JSON up: {“stat”:{“time”:“2020-08-30 23:39:49 GMT”,“rxnb”:0,“rxok”:0,“rxfw”:0,“ackr”:0.0,“dwnb”:0,“txnb”:0}}
INFO: [up] PUSH_ACK received in 2 ms
INFO: [down] PULL_ACK received in 0 ms
INFO: [down] PULL_ACK received in 2 ms
INFO: [down] PULL_ACK received in 0 ms

2020-08-30 23:40:19 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: 100.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

BEACON queued: 0

BEACON sent so far: 0

BEACON rejected: 0

Can you take a photo like this?

1 Like

Today I am not able to do this. I
It is 70Km away from me just now.
Tuesday I will do this and post.
In the mean time I have a photo of the other side but I see the importance of the resistor being on the correct pads.

The rak2247 has 8 channels configured in global_conf.json, and the node also needs to configure the same 8 channels. Only in this way can the rak2247 receive the data sent by the node.

Indeed, yes.
903.900Mhz
904.100Mhz
904.300Mhz
904.500Mhz
904.700Mhz
904.900Mhz
905.100Mhz
905.300Mhz
I have log files I could send of my nodes connecting to Helium hotspots on each of these frequencies.

And here is the back side of my RAK2247_USB

Dear AppleMuncy,

What are the frequency points of your nodes?

Greetings @Nicholas,
I compile my Adafruit 32u4RFM95’s with the example file helium-us915.ino using the MCCI-catena Arduino-LMIC library.
Line 308: LMIC_selectSubBand(1);
sets up SubBand 2 upload frequencies to those I listed before.
903.900Mhz
904.100Mhz
904.300Mhz
904.500Mhz
904.700Mhz
904.900Mhz
905.100Mhz
905.300Mhz

I pull in my global_conf.json with
wget https://helium-media.s3-us-west-2.amazonaws.com/global_conf.json

It would be really helpful if you could confirm that the node has actually transmitted, for example by receiving packets at the same time with another gateway.

Normally you do not want a node to be too close to the gateway, but you might also try bringing the node right next to the gateway, and looking if you get anything (even CRC error packets) as then you might manage to get some signal past any possible faults on the RF or antenna circuitry of the node or gateway.

Right now it seems most likely that the node isn’t actually transmitting during this experiment, so try to think of a way to confirm that it really is, not only that it is supposed to be.

Thanks for jumping in Chris.

i did see this as a possibility when I first start testing this setup.
In fact I noticed than my end nodes did not give any indication they were working unless they where hooked up to a serial monitor. I modified the sketch so they would toggle the LED each time they tried to join. And I learned that in fact they did block waiting for serial to open. I modified the sketch to not let that happen. Now I am confident that when plugged in and blinking they are transmitting.
Your suggestion to take my setup close enough to another hot spot is good. If I still have this RAK2247 next Tuesday I will do that. Thanks.

I realized that this does not come into play on the RAX2247-USB because SPI is controlled
rak_common_for_gateway/lora/rak2247_usb/lora_gateway/libloragw/src/loragw_spi.ftdi.c
by changing
mpsse = OpenIndex(VID,PID,SPI0, SIX_MHZ, MSB, IFACE_A, NULL, NULL, 0);
to
mpsse = OpenIndex(VID,PID,SPI0, ONE_MHZ, MSB, IFACE_A, NULL, NULL, 0);

So I did that but no change in behavior. Still no packets received.
test_loragw_reg fails test_loragw_calfails

I give up. Time to do an R&R.

Dear AppleMuncy,

Can you send a circuit diagram of the baseboard that you connect to RAK2247? I doubt that part of the problem.

No, sorry, not available.

I was searching around RAKwireless for yours and found this in Q&A: of RAK2247

Q: Regarding the mPCIe to USB adapter (With SIM Card) v2, could you please send me the Schematics file? I'd like explanations about the utility of the SIM Card, please.

A: Not sure I can find the schematic, however, this is just a universal board you can also use it with a mPCIe 3G modem card, thus the sim card slot. It does not actually do anything in the context of RAK2247, atleast for now. Now if you want to make some mod and use it that would be awesome and we can continue the discussion in the RAK store facebook channel if you want.

Dear Apply Muncy,

What I want to know is your floor plan, not RAK floor plan.

发件人: Apple Muncy via RAKwireless Forum [email protected]
日期: 2020年9月14日周一 晚上8:28
收件人: [email protected]
主 题: [RAKwireless Forum] [LPWAN Developer Gateways / Concentrators/RAK2245
/ RAK2243] RAK2247_usb fails test_loragw_reg and no packets decoded

And I’m saying I don’t know the floor plan, anymore than the person that answered the same question about the one RAKwireless sells.

Please forgive me if I seem irritated.
And I am at myself for not ordering the RAK2247-USB directly from RAKwireless.
If I had, I would have purchased the mini-PCLe to USB adapter along with it. Then there would be no question about it.
I chose iCEasy Electronics though Amazon to avoid some of the shipping cost and I thought ICEasy was a USA based redistributor. And ICEasy seem like good people but it can be tedious working though those that aren’t technically knowledgeable about a product.

And of course those people that are technically knowledgeable about a product are very valuable and their time should not betaken up on small matters.

So deep in the source code that comes from Semtech are some test programs that get built during RAKwireless’s install.
These programs end up in …/rak_common_for_gateway/lora/rak2247_usb/lora_gateway/libloragw
test_loragw_ cal
test_loragw_hal
test_loragw_ reg
test_loragw_spi
Somewhere in a previous post in this thread I tell about running the four individual tests that test_loragw_spi does and get pass results from each of the four.
Also test_loragw_reg runs returns ~98% good results. It is the 2% incorrect results I do not know how to interpret.
All this leads me to believe the adapter board works fine and most the low level stuff on RAK2247 but deep inside is a problem.
Anyway ICEasy tells me you people at RAKwireless are going to ship me a replacement.
Till it arrives I will focus on other things.

And in particular I first noticed the RAKwireless news about seeking beta testers in the WisBlock test program. It looks interesting. I put in an application : )

Dear AppleMuncy,

I am happy to answer for you. If everything is in good condition on your PCIE bottom plate, then the problem will appear on RAK2247. We will replace a new product for you soon, so as to ensure your normal work.

Best regards!