Single Channel Packet Forwarder part 1 [Deprecated]

[ursm]

reading and understanding the headline is always a good idea.
and I did not recognize that the node changes the channel each time it sends a packet.
thanks @Thomas , @Batilan for their explanation

[popcorn]

@Thomas
Should we give the Testing gateway a specific mac-adress?
https://www.thethingsnetwork.org/forum/t/www-ttnmap-org-alpha/891/3

Maybe something start / end → MAC: “1CHA” ??

[telkamp (Thomas Telkamp)]

@popcorn Please don’t make up your own prefixes. The single channel gateway now uses MAC-48 to EUI-64 conversion for the gateway ID.

Gateways send a platform field in their stat updates, that can be used to identify the type. We should make that available in the API for this purpose.

[popcorn]

Thanks. I will wait a bit for that :D.

[engvidal (vidal)]

Hi. Can I adjust it to 915 MHz just editing line 74

from:
uint32_t freq = 868100000; // in Mhz! (868.1)

to
uint32_t freq = 915000000; // in Mhz! (915)

vidal

[telkamp (Thomas Telkamp)]

Hi Vidal,

Yes, that should work. You probably want to set the single channel center to 915.1 Mhz then (it is 125 kHz wide).

Thomas

[Fabi (Fabian Tietz)]

Another HopeRF SX1276 based packet forwarder is working fine.

One remark regarding wiring. WiringPi takes care of the SPI chip select itsself,
so there is no need to manually handle the chip select, if you connect nss to CE0
or CE1 (corresponds to CHANNEL=0 or CHANNEL=1 in WiringPi).

Found it out by accident, because initially I had connected reset to CE0 (bad idea).

[telkamp (Thomas Telkamp)]

Thanks for the remark, I had noted it too, it is a left-over from experimentation to get this to work. I’ll change it in wiring instructions, with a note, but leave the manual select in the code for a while to not break on existing hardware.

[IoT_Marco]

Hi,

Nice project but something wrong with my configuration:

I build the Single Channel Gateway with a RFM95W and a Raspberry Pi B+. The code is from https://github.com/tftelkamp/single_chan_pkt_fwd and running on Raspbian Wheezy.

When I start the package forwarder I get the error:

“Unrecognized Transceiver”

I’ve searched for that error and found in the main.cpp:

#####################
void SetupLoRa()
{

digitalWrite(RST, HIGH);
delay(100);
digitalWrite(RST, LOW);
delay(100);

byte version = readRegister(REG_VERSION);

if (version == 0x22) {
    // sx1272
    printf("SX1272 detected, starting.\n");
    sx1272 = true;
} else {
    // sx1276?
    digitalWrite(RST, LOW);
    delay(100);
    digitalWrite(RST, HIGH);
    delay(100);
    version = readRegister(REG_VERSION);
    if (version == 0x12) {
        // sx1276
        printf("SX1276 detected, starting.\n");
        sx1272 = false;
    } else {
        printf("Unrecognized transceiver.\n");
        //printf("Version: 0x%x\n",version);
        exit(1);
    }
}  

##############################

I thought that HopeRFM95W is compatible with the SX1276.
Any ideas what coud be wrong here?

[telkamp (Thomas Telkamp)]

Hi Marco,

Your setup looks fine, but most likely the wiring is not correct. It simply doesn’t see your RFM95W.

[IoT_Marco]

Hi Thomas,

Thank you for the reply,
I’m just going back upstairs to my workbench for checking the wires

[IoT_Marco]

Hi Thomas,

Yes, MISO was broken (the wire ;-).,and my Single Channel Gateway is working now!

OK, I have to admit, there are easier ways to attach a HopeRF module to your RPi but, I got an idea and then it is a nice challenge to design, print and assemble these parts.

Printed parts

.

.

.

…and it looks like I’m recieving packets??..is there a node in the area?

rxpk update: {“rxpk”:[{“tmst”:3628397007,“chan”:0,“rfch”:0,“freq”:868.100000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW 125”,“codr”:“4/5”,“lsnr”:10,“rssi”:-68,“size”:63,“data”:“QAE7AQKAJwAFAasyOToyYGXKRgV5eRRCqcwTa2KGQLODV9R1sCFaOnwJ Jg9kAYMboXDmFT9mPkUQkaHQvmTV”}]}

[ernestopace]

Hi Marco,

It certainly looks like there is a node in your area from your logging (line starting with “rxpk update:” indicate received packets.

Remember that your gateway only listens to one “channel”, while nodes switch channels constantly. This means you will see something like one in ten packets with the single channel gateway.

Nice setup, BTW. Mine looks like this:

Ernst

[IoT_Marco]

Yeah, I’m curious who is sending. Nice setup…KIS (keep it simple

[kersing (Jac Kersing)]

@Thomas

leave the manual select in the code for a while to not break on existing hardware.

Yes, please keep it available as modifying the hardware is a pain with wires terminating underneath the RFM adapter board.

[IoT_Marco]

I got a working gateway and a working node. I do receive packets from a unknown node but:

Why is my gateway not visible with the API or Mqtt on thethingsnetwork?
What can be the reason that I can’t see any packets from my working node?

Any help will be appreciated

[pz1]

Network seems to be down since yesterday evening

[Batilan]

Continuing the discussion from Migrated demonstration back-end: restart packet forwarders:

@johan

After some issues related to available disk space and a corrupt Docker installation, I had to reinstall the demonstration back-end on a new instance. The host name is still the same: croft.thethings.girovito.nl, but the IP address has changed to 54.72.145.119. This may mean that packet forwarders should be restarted, either by restarting the packet forwarder or restarting the gateway. My apologies for any inconvenience.

So the single channel gateway needs a code change:

Change #define SERVER1 "54.229.214.112" to
#define SERVER1 "54.72.145.119" 

The code will probably be adjusted to use name resolving.

Note: I adjusted this post to contain the “final” IP address so people don’t get confused by a post containing an adjustment that was only valid for an hour or so. A version of the single channel gateway with name resolving is on the way.

[IoT_Marco]

@Batilan

54.194.88.175

Yes I changed the IP address and compiled again…but at the moment it doesn’t work.
By the way I can’t ping that ip address

[Batilan]

Shortly after I posted my message the IP address changed again , it is now an “elastic IP” which can be reused for future instances too. So the line should become:
#define SERVER1 "54.72.145.119"

Note that at the moment the API is not able to connect to the database:
> HTTP 200 OK
> Content-Type: application/json
> Allow: GET, HEAD, OPTIONS
> Vary: Accept
> {
> “error”: “Cannot connect to database!”
> }