We are using RAKL2287 on our custom board using PCIe connected to Raspberry Pi 3A+ over USB. Is there any simple USB example to establish the connection between RPI and the RAK2287?
On powering up, I do not see any LED on the RAK2287 module and even no USB device is observed in dmesg. I’m seeing the following if it is helpful
[ 26.192245] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 26.192827] hub 1-1:1.0: USB hub found
[ 26.192911] hub 1-1:1.0: 4 ports detected
[ 26.511943] usb 1-1.2: new full-speed USB device number 5 using dwc_otg
[ 26.643944] usb 1-1.2: New USB device found, idVendor=0fe6, idProduct=9700, bcdDevice= 1.01
[ 26.643955] usb 1-1.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[ 26.643960] usb 1-1.2: Product: USB 2.0 10/100M Ethernet Adaptor
[ 26.665847] dm9601 1-1.2:1.0 eth0: register 'dm9601' at usb-3f980000.usb-1.2, Davicom DM96xx USB 10/100 Ethernet, 00:e0:4c:53:44:58
[ 26.861381] dm9601 1-1.2:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xFFFF
0fe6 9700 is your USB-based Ethernet, and apparently the only USB device being recognized in the system.
Which version of the RAK2287 do you have? Apparently only the RAK2287-AY has the MCU populated and supports USB, the RAK2287-SY and RAK2287-MY are SPI only.
Assuming you have the USB model, what can you say about the “custom board” hosting this? Are you certain it is providing 3v3 power on all of the appropriate pin pairs, and that the embedded USB data pins are wired correctly. What is the state of the mPCIe reset signal?
Can you try something else in the slot like an LTE modem and see if that is recognized?
Can you try the RAK2287 in an external mPCIe-USB adapte?r (just make sure it’s one with a regulator that only outputs 3v3, some are cranked to output too high a voltage).
FWIW if making a custom board to host a concentrator, routing SPI signals to the card on the pins where the RAK concentrators need them is likely preferable to USB. Of course you can also route USB if you want to have that option. There should be no conflict, but you can always put little 0402 0-ohm jumpers right at the connector if you want a disconnect option.
Thanks for the response. Where can I know which RAK2287 I received? I have ordered RAK2287 WisLink LPWAN concentrator with order number #5036.
Regarding the custom board, we use it with Quectel EC25 and it works perfectly. I was expecting it to work out of the box with RAK2287. Do I need some drivers for it to recognise on RPI?
Probably only RAK can answer that, I’m going off the descriptions at
I see now that the “Y” in the model numbers I mentioned before is actually a placeholder for a digit representing the region.
If I had to guess though, my guess would be you have an SPI version not a USB version. Or at least if I look in the online store, the text mentions SPI and there doesn’t seem to be any option to order a USB version.
@cstratton is right, seeing how the USB version is not sold yet, you almost assuredly have the SPI version if you ordered from our store, thus missing the STM32 that makes it the USB version.
I will try to check with sales as to the order status, but I am pretty sure it is too early for you to have a RAK2287 USB.
What made you think you were buying the USB version to begin with, perhaps there is misleading information in our store?
While ordering, the website gave me an option to choose an here to choose a USB variant. While doing the final order I went for 2287 instead of 2247 and not realizing that 2287 does not have a USB interface.
Given that I have received an SPI version, is there any documentation available to understand how I can communicate and decode messages received from RAK4600 module.
I only see an option to either uses a preconfigured RPI image having ChirpStack or TTN. I would like to interact directly with C or Python language over SPI.
A gateway typically doesn’t really understand anything about the traffic flowing through it, rather what the packet forwarder program does is translate in both directions between LoRa air packets, and a UDP backhaul protocol documented in the source code.
If you don’t want to use a LoRaWAN network server, then you’d be trying to come up with something else to drop into that role, either implementing LoRaWAN or some other protocol scheme for how nodes interact with the central system. Likely you want to keep that remote, but you can also point the UDP at the loopback interface if you want to run your code on the gateway’s computer.
If you want to operate the hardware with something other than a packet forwarder, there are some low level test tools alongside the code, but you’ll likely not be able to do much without using or studying the existing code - the data sheet is mostly about electrical specifications and interface details, but leaves out a lot about how to actually operate the radio. Fortunately the code is open with reasonable comments.
I’d strongly suggest working with LoRaWAN as is for a while to gain some experience and deep understanding of it before going your own way in terms of either re-implementation or re-design.