Has anyone tried the RisingHF gateway boards?

Or maybe use the official TTN packet forwarder, which saves you time :wink:

1 Like

Thank you kersing for your feedback , its the global_conf.json itself and believe me it had worked for me few months a go ! and i’m configuring json files according to this
i’m trying to connect to ttn-router-eu and port number is 1901. is this ok?

Please read my previous message. The port to use is 1700, not 1901. Your global_conf.json should be downloaded from the TTN github site (see my previous message for the link) and the gateway specific parameters like ID should be in the local_conf.json.
Or as @Epyon suggested, use the official TTN packet forwarder or the use resin.io with these sources.

thank you kersing , it worked !!!. i was confused with 1901 port as mentioned in the “settings” -.>“router” .
Can anyone tell me as why they have mentioned 1901 port ?

Thank you in advance!!

Hi Guys

I am experimenting with lorawan so i decide to buy the developer kit in risighf, My gateway recive the packets and they show in the ttn website but i lose more than 50% of the packets, and the node is very close from the gateway no more than 2 meters, Do you have any suggestion ?
I am using the RHF76-052 configurated in 915 Mhz for a node and for gateway RHF0M301

less then 2 meters is to close !

Just curious why it needs to be further away from the gateway. From my experience with RF system, the closer will have higher chances of receiving the signal. Is this case doesn’t apply for LoRa?

LoRaWAN receivers are very sensitive, especially when coupled with an antenna that has some gain. If you place a node next to a gateway you are overloading the receiver, which will result in many CRC fails for your and other nodes. You don’t place a FM radio right next to a 100kW transmitter, right? Datasheets such as the one from IMST stipulate you should keep at least 2m distance between a node and a gateway to prevent errors or even damage to the gateway. The same goes for node-to-node distance.

Also, in RF it is generally recommended to keep a distance of one to multiple times the wavelength between sender and receiver.

This is associated with the radio Near Field (Fresnel) and Far Field (Fraunhoffer). See https://en.wikipedia.org/wiki/Near_and_far_field . Most radio systems, including LoRa, modulate and use the far field. If you locate transmitter and receiver in the near field they might or might not work and may produce strange results. LoRaWAN in EU at 868MHz uses a wavelength of 33cm. There is no hard near/far boundary but it’s best to keep at least 4 wavelengths between transmitter and receiver. For workshop commissioning I use 2m, i.e. 6x wavelength as my reference test point. As a point of interest some radio systems specifically use the near field, e.g. RFID, bank cards, etc. in order to limit the range and provide power. They are called Near Field Communications systems.

I had the same problems. It was a huge headache, but eventually I figured it out, and I made an instructable for it: http://www.instructables.com/id/LoRaWAN-Gateway-Seeeduino-Motes/

I also talk about this in this thread: Seeeduino US working

And I’ve uploaded the correct end-device Arduino code for using a hybrid gateway here: https://github.com/brady-aiello/Seeeduino_LoRaWAN_for_hybrid_gateways

Long story short: It drops the packets because it’s not listening on those channels. The code that Seeeduino gives us assumes that we are using a full gateway (which listens on all 64 channels), when it reality, our Rising HF gateway is only listening (and transmitting) on 8 channels. So we just need to make sure that the gateway and the nodes are using the same 8 channels.

1 Like

I too have purchased on of the Rising HF 2S001 Discovery Kits. They now are now shipped with an RPi model 3 which gives them more grunt. RHF bundles an FTDI adaptor so you can communicate via a USB port for initial configuration.
The kit is very well put together and easy to get running. Mine is now feeding to TTN with some test nodes.
It is important to note that the 8 channel limitation referred to by Brady is a factor of the Semtech Gateway chipset and effects ALL gateways. To make a 64 channel Gateway, you would need 8 of the modules. And very few people have tackled that task to date. From a practical view, that means the capacity of a Gateway drops to 1/8th of the claimed figure.

So, I’ve set up the risinghf hardware and ssh into it. I cloned ttn’s ic880a and run install.sh
what’s next? I am rather lost as to what the proper steps are in installing and then testing the connection and functioning of the gateway. Many wikis skip steps, so any help is appreciated. Thank you all.

@jmarcelino could you tell me the exact steps you followed? I’m struggling with the same exact setup. Newbie here. the .json file is merged into the ttn repo an the account is set on the ttn site itself.

error: The following untracked working tree files would be overwritten by merge:
B827EBFFFE386695.json
Please move or remove them before you can merge.
Aborting

Not sure what to do next.

So far, I’ve cloned the ic880 repo, the start.sh file didn’t have the reset pin reference since it was the master file. I ran " sudo ./install.sh spi " and get that error at the end when i select Yes to use the remote config file. But start.sh now changes to the spi branch, so I can edit the reset pin, which I think was mentioned is 7 for the risinghf adapter?

a bit confused and lost about what I’m doing wrong. any help is appreciated.

Hi check our instructions

Disclaimers we still need to add to the video:

  1. Never start your RisingHF board without an antenna connected
  2. Don’t use any 2nd TTN Gateway in the config, it causes pakcets sent to all servers/thus flooding (video @12:30)
1 Like

Man this worked awesome for me. I bought the RHF0M301 standalone board last year and have been using jumper wires to bodge the thing together. That was annoying, so I went about looking for the RHF4T002 board only to find that they flat out refuse to sell it except as part of the gateway bundle. Finally ran into this post, had the PCB made, and finally got around to assembling it today. Everything works just like it should! Thanks for taking the effort to design this and then share it with us here!

1 Like

Hi everybody
can you share an SD image working with TTN?

I have the same issue:

error: The following untracked working tree files would be overwritten by merge:
B827EBFFFEFCDAA2.json
Please move or remove them before you merge.
Aborting

Do you know how to solve it?

Hi there,
I’m trying to use the Gateway frm Seeed with RHF0M301 and I followed the steps from : https://www.thethingsnetwork.org/labs/story/seedstudio-lorawan-gateway-built-on-risinghf

But I have a question, if I use only wifi without ethernet, how do I do when I register my gateway on TTN?
Should I put the Mac address of wlan0 or the one of eth0?? Because when I run : sudo ./install.sh spi
I get : Detected EUI XXXXXXXXXXXXXXXX from eth0 but I don’t use eth0 at all…

Thanks in advance for help!

You ‘normally’ use the ethernet mac to derive the eUI - even if not using it to connect - unless using a RPi 0w of course! :slight_smile: The (RPi) script grabs the network i/f info and uses that to derive the code.

1 Like

The reality is it basically doesn’t matter what your gateway EUI is, so long as:

  1. Nobody else is using it, which is the benefit of basing it on an allegedly unique-in-the-world network MAC

  2. You use the same one when registering and in all attempts to run the gateway; that’s the challenge of using a network interface on a board that might have more than one network interface…

One good strategy: let the MAC-based derivation run once then hard-code the result in the configuration file. Just don’t clone the card from one gateway to make another, without changing that(!)

1 Like