RAK2245 96 Board with pi zero

Hi, i am trying running the R2245 96 board with raspi zero w but with no luck…
i ive connected following pizero pins with the 96 er board:

i used the new RAK Stoftware

and choosed zhe RAK2245. but its not running.

I hope there is any one who can help me to resolve the problem.
Regards
patrik

Hi @pacmenDE,

Where did you get the pin mapping image from, is this the official RAK one.
Normally you have an EEPROM for remapping the pins, this is why the RAK2245 Pi HAT exists.

This might be an useful document to refer to to shed some light:

Page 3 has the correct pin-out, which however is remapped for the RAK2245 Pi HAT, this is not the case with the RAK2245 96Boards I believe.
I hope this helps

Regards
Vladislav

Hi hobo,
i used the user manual for 96 board.
https://downloads.rakwireless.com/en/LoRa/RAK2245-96Boards/Hardware-Specification/RAK2245-96Boards_User_Manual_V1.2.pdf to connect the raspi zero.

what i´ve checked and modified is:
:/opt/ttn-gateway/packet_forwarder/lora_pkt_fwd set_eui.sh
GATEWAY_EUI_NIC=“wlan0”
So i get the right GWEUI in local_conf.json

The SX1301 reset pin is on GPIO17 (phys. raspi PIN No 11)
SPI is enabled:
[email protected]:/opt/ttn-gateway/packet_forwarder/lora_pkt_fwd $ ls -l /dev/spi*
crw-rw---- 1 root spi 153, 0 Jul 24 05:36 /dev/spidev0.0
crw-rw---- 1 root spi 153, 1 Jul 24 05:36 /dev/spidev0.1

and i tested with spitest
[email protected]:~ $ ./spidev_test -D /dev/spidev0.1
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)
[email protected]:~ $ ./spidev_test -D /dev/spidev0.0
spi mode: 0x0
bits per word: 8
max speed: 500000 Hz (500 KHz)

But the packet forwarder will not start…

to start i used the start script under /opt/ttn-gateway/packet_forwarder/lora_pkt_fwd $ sudo ./start.sh

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
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 867500000, RSSI offset -166.000000, tx enabled 1, tx_notch_freq 0
INFO: radio 1 enabled (type SX1257), center frequency 868500000, RSSI offset -166.000000, tx enabled 0, tx_notch_freq 0
INFO: Lora multi-SF channel 0> radio 1, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 1> radio 1, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 2> radio 1, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 3> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 4> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 5> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 6> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora multi-SF channel 7> radio 0, IF 400000 Hz, 125 kHz bw, SF 7 to 12
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7
INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to XXXXXXXXXXXXXXXXXX
INFO: server hostname or IP address is configured to “router.eu.thethings.network”
INFO: upstream port is configured to “1700”
INFO: downstream port is configured to “1700”
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/ttyAMA0”
INFO: Reference latitude is configured to 10.000000 deg
INFO: Reference longitude is configured to 20.000000 deg
INFO: Reference altitude is configured to -1 meters
INFO: fake GPS is disabled
INFO: Auto-quit after 6 non-acknowledged PULL_DATA
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 XXXXXXXXXXXXXX
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/ttyAMA0 open for GPS synchronization
ERROR: [main] failed to start the concentrator

What else can be the reason?
Regards,
Patrik

Some things to check
Have you connected the Radio Reset which is normally connected to GPIO 17 (header pin 11) on the Pi. You can check for the required GPIO pin by inspecting the code in start.sh
This should connect to Pin6 on the 96 connector

Have you connected Pin 35 on the 96 connector to 3.3Volt? This pin sets the inputs of the RAK2245 to work correctly in either a 1.8volt system or a 3.3volt system.

You also need to reduce the SPI clock speed to 2MHz to work with the RAK2245. This should have been taken care of in the code from RAK provided you use the RAK2245 code and not try and use some older code for the 831.

Hi Tony,
thanks for your ideas,
Point 1 Reset PIN is mapped with GPIO 17 and i changed the code in start.sh.

I have connected 96 board pin 37 (5V) with the raspi.5 Volt pin. You mean, that the 96 board is produced to un with 3,3 or 1,8 Volt correctly?

Reduce the SPI spped: BCM2835 driver supports these speeds settings
image

Is the Raspi not capable with 96 board?
Which file i have to touch to change the spi speed?

Thanks in advance.
Patrik

First, I have a working gateway using a RAK2245 with a PiZero, So yes, it works with a PiZero or any other Pi for that matter.

I use the Stamp version of the RAK2245 and there is little difference with the 96 Board version. Simply the Stamp unit does not have the 96Board socket fitted. With the 96Board version, you have the option to connect via the 96Board connector OR via the Solder pads on the side of the PCB. Since I have no socket, I connect via the solder pads on the side of the PCB. If I wanted I could solder wires into the holes used by the 96 Board socket.

You need to connect the 96Board pin 37 to 3.3Volts, which is Header Pin 1 on the RasPi. I have no idea of the switching voltage when pin 37 is connected to 5 volts, it may or may not work correctly with a Pi. However I know it works with Pin37 connected to 3.3volt.

For your information
– the Raspi GPIO works on 3.3 volts, which requires Pin37 connected to 3.3 volts
– the 96Board system work on 1.8 volts which requires Pin37 connected to 1.8 volts.

When I changed the SPI speed I edited one of the source code programs and recompiled the Semtech packet forwarder code. This was early this year when the RAK2245 was first released but since then this has been provided by RAK and incorporated in the RAK2245 packet forwarder. My point was don’t try and use the standard Packet Forwarder provided by The Things Network or LoraServer.io as they normally set SPI speed at 8MHz.

Hope this is enough to get it working

Yeah it´s working now …thanks Tony.

External 5 Volt power to PIN 37 and the IOREF pin from 96 board to 3.3 Raspi pin.:slight_smile:

Thank you…!!!

Now i have one of the smallest lora gateway ever!! :slight_smile:

Patrik

How small have you achieved?

case would be 10 cm x 10 cm x 6 cm ip66 box…

Nice. I’ve gone for a tube, 5cm OD x 50cm long, includes Gateway, antenna, POE power supply and ethernet circuits. Currently building 20 units.

Now i have to check LinkIt MT7688 as SoC it´s running with opwenwrt and SD Card is not requiered…

nice format!!
You sell the devices?

Will sell in the near future.

BTW, I agree with other SoCs like the MT7688. I’ve tested a few, some have problems with the SPI port, others have limited supply. As a result, I still haven’t settled on a preferred SoC.

Yes i know. the SPI issue. but it seams there is a spi patch for thi issue. After patching the kernel SPI runs on half duplex mode and the problem is resolved.

I’d be interested to hear how you get on with the MT7688 or any other SoC with the SPI in Half Duplex mode. I thought the Semtech SX1301 radio chip required full duplex but I’m keen to learn from your experience.

The RAK repos show a solution for this, for example the following patch:

I believe what they are doing is actually splitting an SPI “transfer” operation used as a “read” into two distinct SPI operations without a change of the /CS pin in between:

First they do a “write” to send the command such as the register to be read, the result of this would be ignored.

Then they do a “read” to get the data

As far as the SX1301 is concerned this is a single bi-directional transaction (as the chip select does not change), but as far as the MT7628 is concerned, it is two distinct operations, a write followed by a read.

Clever!

1 Like

Thanks for the explanation, most appreciated.