Issues connecting BasicStation to TTN

hello,
I’ve been trying to connect a BasicStation build to a TTN LNS for a while now without much luck. I’ve created keys and trust files. I’ve tried both LNS and CUPS connections and neither seem to work. I was getting TLS certificate errors, but I seem to have that resolved. I still think it is an authentication issue, but I am unsure where to go next. I have the gateway configured on TTN properly as per instructions I’ve read.

I’ve set environment variable STATION_TLSDBG=4 to get a more verbose output from the station, but I’m not sure what to do with it. I have an output capture attached. can someone please shed any light on what is wrong or what I need to try next?

Many thanks.
station-output.txt (223.6 KB)

Hi @mpittman,

using STATION_TLSDBG=4 for debugging network related issues is a good move! :+1:
The logs show the last message from the server before the server closes the connection:

HTTP/1.1 400 Bad Request
Cache-Control: no-store
Content-Type: application/json
Pragma: no-cache
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Rate-Limit-Available: 9
X-Rate-Limit-Limit: 10
X-Rate-Limit-Reset: 6
X-Rate-Limit-Retry: 0
X-Request-Id: 01GEQ6458RW9V7HXCRKYZHZ64P
X-Xss-Protection: 1; mode=block
Date: Thu, 06 Oct 2022 17:40:07 GMT
Content-Length: 312

{
        "code": 3,
        "message": "error:pkg/auth:token (invalid token)",
        "details": [
                {
                        "@type": "type.googleapis.com/ttn.lorawan.v3.ErrorDetails",
                        "namespace": "pkg/auth",
                        "name": "token",
                        "message_format": "invalid token",
                        "correlation_id": "0f038d6ccb5f4ae58392463ae3b44907",
                        "code": 3
                }
        ]
}

Further up the log I see

GET /router-info HTTP/1.1
Host: nam1.cloud.thethings.network:8887
Upgrade: websocket
Connection: upgrade
Sec-WebSocket-Key: bpse8nVmEl6ZlX4lSb6RMw==
Sec-WebSocket-Version: 13
Authorization: Bearer ITNPQWMP****7OD7L4SEQBAKE****WMBAZUCPWY

(I added the *s). The Token doesn’t look right to me. The token is typically a longer string starting with NNSXS and with dots in between. Here is one example:

NNSXS.GIKB7DP****AEOZTP****ZXIRT****ZY7BLXEEY.XPN**STG****K3KL6U3KT****UAGHBBLTKHUB****2C7Q**T37ZA
1 Like

ok thanks. I’ll look into that.

That was it !! I somehow copied and pasted only a portion of the API keys which was the issue. I can connect to the network server now. Unfortunately, I’m still having an issue with the Gateway disconnecting right away because the Concentrator fails to start? Appears to be an issue with the SPI? I know SPI and I2C are enabled on the PI board. I’ve checked the GPIO pins in reset_lgw.sh and they appear to be correct. I can’t even get the chip_id utility to work with SPI. Works fine over USB. Is it possible to get the station to use USB instead of SPI?

capture.txt (19.2 KB)

Double check and then check also that logical and physical are correct and mapped…which condccard & which host computer/embedded card? Direct or via an intermediate interface card? Again if latter which one?

Update: I see its PI but which flavour?

BasicStation does not support USB.

EDIT: I should have checked the current code before making a statement, for SX1302 it does support USB these days.

I’m using the SX1302CSS915GW1 dev kit from SemTech.

So the PI (PI 4 model B) is connected to a 1302 corecell via the dev board. Since this is a commercial dev kit, I expect it is not a wiring/connection issue (unless it is just bad HW?).

Here is the output of the “pinout” command on the PI:

image

And the schematic/pinout of the PI connector on the schematic for the interface/dev board:

image

And here are the PIN assignments in reset_lgw.sh:

image

So as far as I can tell, everything is set correctly??

However, when I run “./chip_id -d /dev/spidev.0.0” I get this:

CoreCell reset through GPIO23…
SX1261 reset through GPIO22…
CoreCell power enable through GPIO18…
CoreCell ADC reset through GPIO13…
Opening SPI communication interface
Note: chip version is 0x00 (v0.0)
ERROR: Failed to set SX1250_0 in STANDBY_RC mode
ERROR: failed to setup radio 0
ERROR: failed to start the gateway

I dont have this kit to hand to check but can you validate conections - Pi connection/schematic suggests GPIO4 → PIN 16 for SX1302 RESET, where reset_lgw.sh assignments suggest PIN=23…I need to go look at the Broadcom pinout (used to have in mind but not looked for a while) but late here and just packing up for the night…please double check…

Was sure PIN 16 on the connector was GPIO23…? (As called out in the listing you have given)

I have tried reset_lgw.sh set with GPIO pin assignments that match how the schematic has them labelled vs what the PI pinout says and no luck. (ie. using GPIO 4,1 & 3 instead of 23, 22 & 18)

I’m not quite sure why the semtech schematic pin labels don’t match the PI labels, but I figure the PI GPIO labels should be correct.

I’ll keep checking. Thanks.

For ref:
image

I will get chance to look again tomorrow but hopefully someone else will step in and call out the obvious by the time I eyeball again (@kersing , @descartes ?)

Looking at the schematic for the 1302 corecell itself, I noticed that there are a bunch of inline resistors on the SPI/I2C and control lines. However, they are not installed !! so no wonder the SPI doesn’t work??

image

IS there some reason they wouldn’t be installed? Can you not have these installed if you want to use the USB capability? Not sure why? Anyway, question to go back to SemTech with I guess.

Thanks for your help.

Morning’! I need to find time to pull the ref schematics but if I recall from a quick look a year or 2 back….lost in the fog of lockdowns……the CN490 version is USB stick…I see USB connected? So is that the schematic for the CN490 version?

The 868/915/923 version is SPI enabled…… so expect a schematic where the NC’s are populated……and slightly different form factor….

Also the I2C is enabled for both host and onboard temp sensor use…

Looking at that diagram they are using the WiringPi GPIO names which makes things unnecessarily confusing as the newer software uses Broadcom assignments. But yes, looking at the pin numbers and the Broadcom mapping it looks correct.

Looks like that’s the case. However the good news is that the Semtech 1302 HAL code now does include support for USB (originally it didn’t) so you should be able to use it to build BasicStation with USB support. If you use GitHub - lorabasics/basicstation: LoRa Basics™ Station - The LoRaWAN Gateway Software you should be able to configure for USB.
(It would be strange if Semtech code didn’t support Semtech hardware so I dug around a bit to check)

1 Like

Good spot, you will recall the original SX1301 (&08) USB support was deprecated around 2-3 years BC! Good to see USB back on the agenda :slight_smile: as simplified for some and stops sillies like level shifters being intoduced in some designs then forcing slow down of SPI bus and need to change RPi settings as often caught folk out in the past…

FInally got to one of my eng PC’s rather than iPad over breakfast and see on the schematics for ref design that USB is default!

This schematic and values for components above correspond to the MCU/USB BOM configuration populated by default on the SX1302/03 Corecell V3.
Please refer to the BOM document to obtain values for components of the 2nd SPI configuration option.

Design files, schematics, altium files, BOM xls etc here if anyone interested in details Salesforce

CN490 version is here Salesforce

Nope, the NA 915 version.

See post above :slight_smile:

1 Like

Id prefer to not use USB. Just less integrated with external cable required etc

Then you’ll need to find new hardware or populate the missing resistors on the board.