The hard RAK831 cafe part 2


(Snorkman) #188

Interesting, I am wondering how does itfix to the board, thermal paste also required?


#189

I would guess thermal self-adhesive tape would be used because presumably there are no mechanical mounting points.
On the right picture, the pink-brown material (2 pieces) under the heatsink appears like it is not sticking to anything.
The material has to perform three different functions:

  • As electrical insulator to prevent short-cutting the PCB
  • As heat-resistant glue to mount and keep the heatsink onto the PCB
  • As thermal conductor to transport heat from the PCB to the heatsink.

The heatsink is wider than the PCB. This increases thermal performance but also makes it mechanically less robust and more sensitive to shocks and bumps (and does not help cool the Raspberry Pi MCU).
I’m curious how they are going to attach it.


(John Hunt) #190

It seems that RAK wireless copied the datasheet of iC880A. Typical chinese way of doing business…


(Couin) #191

I’ve found this link :blush:
AliExpress Link - Rak Wireless Store


(Bjacobse) #192

Hi I have had my gateway for a few months, I know that indoor placement with a little whip antenna is not the a good solution. We have quite poor mobile phone coverage as we have gypsic plates with silverfoil in our walls - but anyway I would expect some TX signal going to my gateway that should sniff some RX. So I need some help to debug
What to do?
lora_console_gw
lora_syslog

lora_tcpdump_1700


(Jac Kersing) #193

This looks al perfectly healthy, do you have a node near the gateway? (Not too near, 3-5 meters distance should work)


(Bjacobse) #194

Thanks for a quick reply. Well I don’t have any nodes myself, so I thought that I would receive data from other nodes when they transmit?
I would expect from ttnmapper.org that I would receive adn forward some node-packages
lora_ttn_mapper


(Bjacobse) #195

Now when I look into my log, then I see that It looked like that I have received something, but I got CRC fail
Can this behave due to poor antenna reception?
lora_log_receive


(Jac Kersing) #196

Could be the signal level is too low to receive an undamaged packet. Could be the received data is not a valid packet at all.

Best way to test is to obtain a node and try to send data :smile:
The ttnmapper data could have been obtained last year so your gateway had no chance of receiving it. However the antenna and its position inside a faraday like room will not help. If possible you could position the gateway outside (when it’s dry) for a couple of hours to see if that makes a difference.


(Bjacobse) #197

I have been thinking what could interfere with 868MHz and I somehow wasn’t thinking of my Zwave devices for homeautomation, they also operate on ISM band


I need to extend my Ethernet cable to the garage away from my house, to check if I then can receive some good data packages from somebodies node


(Trunghoang) #204

@TonySmith In my country, the 868MHz frequency is forbidden but I see its popularity in the world :slight_smile:


#205

So you are illegally using that frequency in your country and the TTN network.
Off course we don’t approve that.


(Trunghoang) #206

Has anyone programmed RAk831 with ESP8266 or other MCU? I want to deep understand about communicating SPI between RAk831 and raspberry pi. I reading Lora packet_forword but I have a problem when converting SPI of raspberry Pi to SPI of MCU.


#207

please explain… what did you use as MCU… what did you exactly convert and where can we see the converted code ?


(Trunghoang) #208

hi BoRRoz. I use STM32 to connect RAK831. I want to know what did raspberry pi write/read into the address of RAk831 but I don’t know about SPI of Pi so some line in code I don’t clear.


(Tibbe) #209

Hi!
I don’t know why I am not able to send anything from my RAK831 Gateway to my RFM95 node using util_tx_test.c program (from https://github.com/Lora-net/lora_gateway) as plain LoRa packets. Nothing gets received on the node(using Radio Head library on node).

The log on the RAK831 is fine:
Sending 10 packets on 868400000 Hz (BW 125 kHz, SF 7, CR 1, 16 bytes payload, 8 symbols preamble) at 14 dBm, with 100 ms between each
INFO: concentrator started, packet can be sent
Sending packet number 1 …INFO: tx_start_delay=1495 (1495.500000) - (1497, bw_delay=1.500000, notch_delay=0.000000)
OK

Things I checked:

  • Tested inverted modulation from gateway.
  • Changed SyncWord to 0x12 on end node and set loraWAN_public=false in the code.
  • matched frequency, CR, SF, BW, preamble.

I can send from the RFM95 node to the RAK831 gateway using util_pkt_logger without any problems. I also tried with another Dragino-gateway that could send to the end node without problems, so the end node is fine.

What could be wrong?

Thanks in advance!


#210

Picture from RAK831 + RPi Converter + RPi from the RAK Wireless Module Store.

That GPS antenna picture is truly creative. :wink:

Creative%20GPS%20antenna


(David G) #211

Hi
2 questions,
1
Has anyone got some pointers on how to change the packet forwarder to the TTN one on openwrt?
2
I keep getting “Failed to start concentrator”. About every 5th attempt does start it and then everything works ok. At the moment I am just testing the system and am using the leads that came with the system to join the MCU board to the Rak board. Could this be the cause? and if so are there any ways around this apart from using a PCB to link the two? I have already tried changing the SPI speed but it made no difference, although I might be changing it in the wrong place.


(JerylCook) #212

My RAK831 gateway has been working and online for weeks with no issues including receiving data from my end-devices. Yesterday after performing a reboot I keep getting the below errors. Any thoughts on what this may be? I rebooted a few times but still getting the same error.

Oct  6 16:18:37 ttn-gateway ttn-gateway[430]: # Manual GPS coordinates: latitude 38.88301, longitude -76.94082, altitude 0 m
Oct  6 16:18:37 ttn-gateway ttn-gateway[430]: ##### END #####
Oct  6 16:18:37 ttn-gateway ttn-gateway[430]: INFO: [up] PUSH_ACK for server router.eu.thethings.network received in 98 ms
Oct  6 16:18:37 ttn-gateway ttn-gateway[430]: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 91 ms
Oct  6 16:18:37 ttn-gateway ttn-gateway[430]: INFO: [down] for server router.eu.thethings.network PULL_ACK received in 92 ms
Oct  6 16:19:36 ttn-gateway dhcpcd[458]: eth0: carrier lost
Oct  6 16:19:36 ttn-gateway kernel: [71910.590233] smsc95xx 1-1.1:1.0 eth0: link down
Oct  6 16:19:37 ttn-gateway dhcpcd[458]: eth0: deleting address 2601:141:4000:7d0:d725:4c12:79dc:b901/64
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Withdrawing address record for 2601:141:4000:7d0:d725:4c12:79dc:b901 on eth0.
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Leaving mDNS multicast group on interface eth0.IPv6 with address 2601:141:4000:7d0:d725:4c12:79dc:b901.
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::a768:bc25:55d6:1a0c.
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Registering new address record for fe80::a768:bc25:55d6:1a0c on eth0.*.
Oct  6 16:19:37 ttn-gateway dhcpcd[458]: eth0: deleting default route via fe80::d66e:eff:fe43:7c96
Oct  6 16:19:37 ttn-gateway dhcpcd[458]: eth0: deleting route to 2601:141:4000:7d0::/64
Oct  6 16:19:37 ttn-gateway dhcpcd[458]: eth0: deleting address fe80::a768:bc25:55d6:1a0c
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Withdrawing address record for fe80::a768:bc25:55d6:1a0c on eth0.
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::a768:bc25:55d6:1a0c.
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Interface eth0.IPv6 no longer relevant for mDNS.
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Withdrawing address record for 192.168.1.12 on eth0.
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.1.12.
Oct  6 16:19:37 ttn-gateway avahi-daemon[435]: Interface eth0.IPv4 no longer relevant for mDNS.
Oct  6 16:19:37 ttn-gateway dhcpcd[458]: eth0: deleting route to 192.168.1.0/24
Oct  6 16:19:37 ttn-gateway dhcpcd[458]: eth0: deleting default route via 192.168.1.1
Oct  6 16:19:39 ttn-gateway ntpd[605]: Deleting interface #13 eth0, 2601:141:4000:7d0:d725:4c12:79dc:b901#123, interface stats: received=8, sent=8, dropped=0, active_time=475 secs
Oct  6 16:19:39 ttn-gateway ntpd[605]: 2600:3c03::f03c:91ff:fed5:767a interface 2601:141:4000:7d0:d725:4c12:79dc:b901 -> (none)

Oct 6 16:19:39 ttn-gateway ntpd[605]: Deleting interface #12 eth0, 192.168.1.12#123, interface stats: received=392, sent=397, dropped=0, active_time=71434 secs
Oct 6 16:19:39 ttn-gateway ntpd[605]: 104.238.179.228 interface 192.168.1.12 -> (none)
Oct 6 16:19:39 ttn-gateway ntpd[605]: 23.239.24.67 interface 192.168.1.12 -> (none)
Oct 6 16:19:39 ttn-gateway ntpd[605]: 159.203.158.197 interface 192.168.1.12 -> (none)
Oct 6 16:19:39 ttn-gateway ntpd[605]: Deleting interface #10 eth0, fe80::a768:bc25:55d6:1a0c#123, interface stats: received=0, sent=1, dropped=0, active_time=71439 secs
Oct 6 16:19:39 ttn-gateway ntpd[605]: peers refreshed


(Bradzcave) #213

I just ordered one, looking forward to contributing because there are so few open gateways in Vancouver Canada.

these two writes up sold me:


https://www.thethingsnetwork.org/labs/story/rak831-lora-gateway-from-package-to-online

I thought I’d try some of the packet forwarders, both of these are well liked/used on things network?


https://github.com/ttn-zh/ic880a-gateway.git ~/ic880a-gateway
https://github.com/ch2i/LoraGW-Setup
or…
https://github.com/hallard/RAK831-Zero

and… is there a command line flag to run the packet_forwarder without the radio module, just to send a test packet to things dashboard?

all the startup guides begin with new image, is that really necessary? easy to enable SPI on most pi’s.

Thanks,
Brad