On my current setup I am using Rak2245 with RPI 3b+. Now, I want to build new gateway (Rak2287 + RPI4 + raspbian is + Chirpstack) Rak2287 seems have better specifications than Rak2245. However, there are very few people and resource that use Rak2287. Is Rak2287 stable and working with chirpstack ? Or should I call continue with Rak2245 ?
If you look at the specs of the sx1302 silicon vs the sx1301 in the RAK2287 vs the RAK2245/RAK833/831 it’s made in a far more modern and power efficient process, which means it doesn’t get as hot - basically the key chip is a digital processor (two helper chips handle the RF) and this one is a later generation processor that just like the chip in a newer laptop is more efficient, and also more capable in terms of simultaneous reception.
Just got a RAK2287 in last week to try, no real complaints. Worth noting that the RAK card does not include the temperature sensor used by the Semtech reference design, so you either have to use RAK’s code repo which partially overrides the base Semtech code it checks out, or similarly disable the temperature reading/compensating logic in the Semtech code if you use that directly.
If you want to make use of the on-board GPS you apparently need UART and/or I2C routing to some pins not needed by previous generation cards; I’ll be modifying one of our host boards to experiment with that, though we usually don’t have sufficient view of the sky for it to matter.
I’ve not tried using this with Chirpstack, and there have been reports of slight data format incompatibilities vs TTN, but the data is generated from C code that is readily editable, so if you need to make changes (making the temperature report an integer, or better removing it entirely since there’s no sensor) that’s not complicated. I think that Chirpstack’s own gateway-side software efforts are looking at the utilized sx1302 chip, though if you want to use that software option you may need to modify it or put in a feature request to work without a temperature sensor - really wish RAK would have included that $ 0.90 part to make it compatible with the reference design.
One thing you do lose is a transmit LED with the precise timing of being direclty driven by the hardware - that occasionally proved useful on earlier boards (especially the RAK833 where it was on the header) to watch on a scope in comparison to node receive windows while fixing node firmware timings. But unless you’re doing node firmware development and have no other gateways to test against, it’s no big deal - there is an LED, and I believe it can be operated with more approximate timing by software but may require a slight edit to drive the correct GPIO. Typically the concentrator card isn’t exposed to view anyway so other status from software is more useful.
I’ve had a 2287 concentrator on a pi3b+ running chirpstack flawlessly, hasn’t needed a reboot for 6 months. Go for it.