Using RAK2245 with RAK2013

LPWAN Developer Gateways / Concentrators RAK2245 / RAK2243
#1

Hello all, I have an issue when using the RAK2245 with the RAK2013 simultaneously. Because both RAKs work fine when I use the separately but when if connect them together ( I used the RAK2245 with an USB to UART adapter) I only manage to get one working at a time. This means when I install the RAK2013 first it works fine. But when I then install the RAK2245 the ppp0 connection is lost and it does not reconnect. I think the pins should not be the problem because they only share the same UART which I do not use for both RAKs.

Setup: I use a Raspberry 3B+ with the RAK2013 on top and the RAK2245 is connected with cables and the USB to UART adapter

#2

Hi @Moritz,

Did you connect your RAK2245 via UART using USB-UART only? Or you connect the SPI lines and other pins like reset as well?

Also, this setup description below is a little bit confusing. UART pins shouldn’t be shared. I think if you can create a simple sketch of the connections of the modules, our gateway experts can give the right suggestion what to check :slight_smile:

#3

Is this related to your existing question Using the RAK2045 with an USB to UART addapter where you were trying to use a USB-UART for the concentrator’s GPS?

One thing to be aware of from the RAK2013 page:

Note that if you buy WisLink Cellular Pi Hat RAK2013 as an individual pice it will not be compatible with WisLink LPWAN RAK2245 RPi Hat and WisGate Developer RAK7243/44(without Cellular) Gateways and vice versa. RAK2245 LPWAN PiHAT module that we use in our WisGate RAK7243/44C(With Cellular) Developer Gateways is modified.

Are you trying to use the RAK2013 via UART or via USB?

If via UART, the packet forwarder might still be trying to open the pi’s UART, and so stealing bytes intended for pppd; look at the packet forwarder config files and the log on startup and make sure it’s using either nothing or your USB-UART, and not /dev/ttyAMA0 or whatever the hardware one is.

If via USB, it’s possible that there might be a conflict with dynamic device names - most modems get names in the /dev/ttyACM[n] range while most USB-UARTs get names in the /dev/ttyUSB[n] range, but there are counter-examples which could confuse software, and might need custom udev rules to sort out.

Really your simplest solution to serial conflicts is probably not to try to use GPS at all - in typical LoRaWAN use cases, it’s actually not useful at all - TDOA location requires additional capabilities not present, and it’s easy to set static location coordinates; the only thing GPS really does for you is give a time source if you’re archiving packets while received offline, but most LoRaWAN network servers can’t ingest logs of past packets in a useful way anyway.

Another possible issue for your failure is that your overall power supply might be insufficient for certain peak loads. Many people mistakenly shop based on average - I’d strongly recommend using a 4 or 5 amp power supply for a pi-based gateway.

1 Like
#4

Hey @carlrowan, I did a sketch as shown below. I hope this is helpful for you.

Verdrahtung
Verdrahtung2406×1072 406 KB

#5

Hey @cstratton , yes this question is related to the existing one. I have the RAK2013 connected via UART (I have posted my sketch above). First of I installed the RAK2245 and made sure that the Packet forwarder is configured on ttyUSB0. But still when installing the Code for the RAK2013 afterwards all the information for my LoRaWAN Gateway is lost (Gateway Id, version).

By now I have not figured out how to deactivate the GPS apart from not connecting Pins 8 & 10.

I checked my power supply and it provides 2.5 Amper do you think that this might not be enough?

#6

That sounds like a software problem. To my understanding, this combination of parts is officially unsupported except when the special versions are bought together as a kit. I’m sure it is possible (at least without trying to use GPS) but you’ll probably need to re-install the gateway packet forwarder manually without using an install script. That’s a worthwhile thing to learn to do anyway - basically use generic LoRaWAN gateway instructions with the appropriate concentrator reset GPIO, and remember to lower the SPI clock speed to 1000000 Hz.

By now I have not figured out how to deactivate the GPS apart from not connecting Pins 8 & 10.

That should work, provided the packet forwarder software doesn’t try to use the pi’s UART either.

I checked my power supply and it provides 2.5 Amper do you think that this might not be enough?

In my experience this is insufficient for reliability, and you want a 4 or 5 amp supply to avoid random issues during brief load peaks. But it sounds like your first issue is a software problem.

#7

Thanks @cstratton, maybe you could explain a little more detailed what you mean with generic LoRaWAN gateway instructions and concentrator reset GPIO. I have never done anything like that so I would appreciate you help.
Thanks in advance

#8

I’m going to suggest you do a web search for existing resources on setting up software for a generic LoRaWan concentrator, rather than try to write a guide in a post which might end up leaving out something.

The one thing you’ll need to do differently from standard is reduce the SPI clock speed in the source checked out from the LoRa Gateway HAL repo. You could also compare the RAK repo to the Semtech one.

Overall though, since you’re wanting to interconnect the hardware in ways a little different than intended, it’s really going to be beneficial to invest some time in learning how the various pieces of a LoRaWan gateway work and interact.

Alternately you could read through the install scripts from the RAK repo and do those things manually, but omit whatever was removing the setup of the mobile data module.

#9

I am also interested in combining the RAK2245 and the RAK2013. We bought the RAK2245 to test out the LoRa features and it works well with just the RPi and the 2245. I was about to add our current cellular hat (a NimbeLink) but realized there would be pin conflicts. There would also be conflicts with Sixfab’s version as well. I looked at the RAK2013 and the pins look like they would not conflict with the RAK2245. However, the notice on the web page saying the two are not compatible concerns me (they work together only when bought together in the dev kit since one is modified).

My questions are:

  1. What specifically is the conflict?
  2. What can be done to mitigate this? Is there an end-user fix or solution that can be applied? Or can a feature (like GPS) just be disabled?

I need a solution that has both a LoRa concentrator and a NA LTE cellular connection and this combo looks like it may work.

Thanks in advance…

#10

Presumably the UART for GPS vs mobile data

  1. What can be done to mitigate this? Is there an end-user fix or solution that can be applied? Or can a feature (like GPS) just be disabled?

Physically cutting traces or pins should work. Do you have any actual use for a GPS?

I need a solution that has both a LoRa concentrator and a NA LTE cellular connection and this combo looks like it may work.

Personally I’d use a USB- rather than UART- based mobile data modem.

I also wouldn’t use a pi, but rather something that does not rely on an SD card. And I’d be sure to save a UART for the Linux console.

#11

I would like to use a USB-based modem and the NimbeLink and Sixfab units are exactly that. I apologize for not looking at the RAK2013 closely but is that USB or UART based? We don’t have a need for GPS as these units are well inside an industrial facility and stationary.

Regarding the RPi, we actually have our own SBC but used an RPi header for peripherals.

#12

I’m not personally familiar with it, but seeing as there’s no USB channel on the pi GPIO header anything connecting to that alone would have to use something else, probably UART.