With special thanks to @kersing who did a major part of the preparations and presented the first of the three gateway workshops.
3 Likes
Hello.
When i saw the picture… 
Yesterday ariving from a nice guy from our community.
And YES he want`s to proof my solderskills!
And @Charles … A big THANK YOU for your marvelous PCB`s. Love them.
Greets
1 Like
Hello.
At the moment at my Wörkbensch.
Building a Freifunk-IoT-outdoor-Gateway.
Starting with a little photosession
Wrote a little bit description in our Forum
And sorry guys, english is not my langauge. ;-p
Feel free to visit our Website to find out more.
Greets and have fun
2 Likes
looks like early Christmas on your table … all nice presents 
1 Like
Christmas? What`s about Eastern? 
Some peaces are spend from the guys from our comm. . Eg WLANRouter, Pi, RAK831.
Much to do! 
1 Like
10 years (for real) without ever changing or charging the node battery ?
NEW!! CH2I XXL - small low powernode + big battery, the new 2018 trend 
- I will use @lex_ph2lb code from his project
3 Likes
removing the PWR Led and the LDO it will continue for 20years
3 Likes
still don’t understand Net Id 0x00 … it’s forwarded by TTN, must be registered by TTN ?
and its not close to me I think ( received with RPI / RAK831 indoor GPA )
Hi Rob I believe the 0x00 may relate to specific test network/test devices (check wrt LoRa Alliance LoRaWAN NetID) - good that TTN is picking up vs dropping the packets/payload.
I think the original LoRaMOTE’s (Semtech/iMST) associated with the SMTC LoRa IoT Dev/Demo Kits may be programmed with this. (I note also running SF12)
If you can decode the payload (Poss through Cayanne?) likely you may get the full LoRaMote payload (GPS Data, Battery level, Barometric pressure/altitude, Temp.). In which case if mote is very remote may help you get some understanding of your gateways coverage via the included GPS signal.
I will be posting my own experience of getting my TTN Gateway up and running this last week in another thread (Central or Status of? TBD) when I have a few moments and fact is that whilst GW came up fine I had no free nodes to test as they were all allocated to other networks & customer or private demoes. By chance I powered up an old LoRaMOTE from my spares box SMTC had given me late 2016 - supposedly dead - and hey presto I caught traffic on my GW - with 0X00. That then prompted me to try another two associated with old SMTC IoT Demo Kit and they were picked up too! Had them running in Thames Valley Tues/Wed night then took them and GW to N.West (along Mersey valley) and had them running there too Friday…so long may TTN support and pass through, please!
Haven’t got my data online right now to check my received payload structure but from memory from your 40 FC 0A 15 00 80 04 00 01… I suspect the Dev Add of the node you are picking up is either 01:00:04:08 or 00:04:80:00 or 04:80:00:15 …perhaps another forum user may recognise and shout up!
Cheers, Jeff
1 Like
If I copied the payload correctly, then it seems this is not using the default Semtech keys, so decoding is impossible. (The DevAddr is not encrypted, and is 0x00150AFC.)
And yes, TTN will handle the test prefixes 0x00 and 0x01, if some TTN user has registered the device.
ah ok so its registered
Actually I wonder now if one can tell it’s actually registered.
Maybe the line “brokers: 6” only indicates it knows of 6 brokers that may be able to handle it, like based on region (maybe including those of Mesh and Switch and maybe including their own commercial instance), as they route using the 0x26 and 0x27 prefix:
Within TTN, we assign device address prefixes to “regions” (for example, device addresses in the
euregion start with0x2601). Within a region, the NetworkServer is responsible for assigning device addresses. We are using prefixes here too for different device classes (for example, ABP devices in theeuregion start with0x26011) or to shard devices over different servers.
(For my own nodes I see “brokers: 1”, which is then only the EU community instance, I’d guess.)
Network: Experimental nodes
Net ID: 0x00
Region: Local
Physical Payload
{
“gw_id”: “brz-gwy1”,
“payload”: “QPwKFQCAPQAByYEv7kmZSBbmmiE+Ft/rvaRfRi0=”,
“f_cnt”: 61,
“lora”: {
“spreading_factor”: 12,
“bandwidth”: 125,
“air_time”: 1646592000
},
“coding_rate”: “4/5”,
“timestamp”: “2018-02-04T15:59:08.067Z”,
“rssi”: -119,
“snr”: -16.75,
“dev_addr”: “00150AFC”,
“frequency”: 868100000
}
airtime 1646.6 ms
if I see something like this its normally more then 10 km distance
I noticed these also on my gateway;
Different device address though but same payload size, SF and BW.
1 Like
nope… somethings wrong 
took a while yesterday to realize I’ve forgotten 2 I2C wires on this just after French lunch designed PCB
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARGH 
so I bought this RAK 811-n breakout board
assuming that it would fit on a NORMAL 2.54 breadboard… nowhere in the advertisement they say otherwise.
and look
So that 2mm pitch instead of 2.54 ?
you could make a breakout board for that:joy:
1 Like
yes probably 2 mm pitch… who in the world uses a 2 mm picth breadboard ?
Just use a xbee adapter 