Replies: 7 comments 3 replies
-
|
Besides CubeCell being a very old platform that doesn't run LoRaWAN well in general due to a poor internal clock, you will get more info from the device by turning on the basic & protocol debug flag (see the wiki page on troubleshooting). Given that the SDR gives a nice 868.1 MHz signal I doubt that the fault is at the device side, but it's an easy starter. |
Beta Was this translation helpful? Give feedback.
-
|
@StevenCellist thank you. Long long log including SPI debug |
Beta Was this translation helpful? Give feedback.
-
|
@d00m178 I said basic & protocol, not SPI :) please disable the SPI flag as it provides way too much clutter. |
Beta Was this translation helpful? Give feedback.
-
|
ok sure Debug output
hmm... SF = 10 and SF = 12.. maybe this is issue? |
Beta Was this translation helpful? Give feedback.
-
|
it would be good to at least know if I configured configABP.h and main program correctly for CubeCell device? I know - there is possibility that it could be issue with GW but its log shows output from simple examples for LoRa, like SX126x_Transmit_Interrupt which running on CubeCell. |
Beta Was this translation helpful? Give feedback.
-
|
Your device looks all good.
This is not the issue - LoRaWAN takes full control over your radio, so you cannot modify the radio directly, this must be done through the LoRaWAN stack, e.g. Make sure your device is at least a few meter and solid (brick) wall away from your gateway - it may be overloading the gateway by shouting through a megaphone. |
Beta Was this translation helpful? Give feedback.
-
|
Some observations:
Whilst the variable timing of the CubeCell makes for poor downlink reception and is overall not at all recommended unless in a thermally stable environment and has it's timing tuned on a board-by-board basis, apart from that, it should be OK to transmit an uplink. |
Beta Was this translation helpful? Give feedback.
-
|
@StevenCellist thank you for answer. I would like to add some details about my project and GW in my environment.
Actually yesterday I decided to ask my full question on Chirpstack forum and I received answer that explained my issue
So now seems it is clear why it doesnt work:
But what about this
? Is it worth to wait it to be ready or it is better to order some real Gateway HW for my RPI4? based on SX1302: Price - 63EUR with RPI Hat or Price - 106 EUR with Rpi Hat btw - why price so different? seems devices pretty the same? based on SX1303 which is slightly better that 1302: Price - 116EUR with RPI Hat Price - 105USD with RPI Hat Which would be better? |
Beta Was this translation helpful? Give feedback.
-
|
The Chirpstack answer isn't strictly accurate due to Single Channel Packet Forwarder's pre-dating Chirpstack. The SCPF was an alternative to a full gateway, tolerated in the early days of LoRaWAN as a full gateway cost in the thousands. But they cause disruption for shared networks - like TTN and anyone peering gateways via PacketBrokers - or a normal setup on any LNS - as you have found out - it can only do one channel when the devices are working on the basis that 8 are available. It has been recognised that there are use cases where a handful of devices in a location need a gateway but a full 8 channel one is overkill - so Semtech have released information sheets and code to run a One-Channel Hub on readily available hardware like the Heltec LoRa32 v3 which Semtech actually used for development. It uses a configuration that does not impact other devices. It's reason for existence is that in theory you can configure a device to use it, so in theory there are already many devices around that can immediately work with it. In practise on most devices you can't lock the channel (frequency) you can use. The next bit is that two things have to happen:
TTS (TTN aka Sandbox & TTI) has an entry for the EU one channel but no docs yet but that hasn't stopped us before.
These will be real gateways, but an 8 channel gateway provides for many many devices - it can cope with 8 uplinks in parallel at the same time - which means most uplinks get through. For a one-channel, there is the potential of uplink loss if two or more devices transmit at the same time - either none or one will get through. But if you have a half-dozen devices and it's not super critical data, it's a good solution. I'll let you take the giant leap of searching for One-Channel Hub information. As for the options for Pi HATS, due to Helium there is a glut of concentrators in the manufacturing pipeline so some are offloading their cards. The SX1303 is only better in terms of less components, better thermals and lower power consumption but not significantly so. Making a concentrator card is no mean feat, so relatively only people that can do and they have to invest in the project and the chips all come from the same place, so within reason they are all of much of a muchness. RAK will provide a better setup experience even if it's a bit of a juggernaut as they do LoRaWAN as thing. WaveShare is often a voyage of discovery. Not tried the Elcrow code offering. Final note, telling us relevant details after the fact is bloody irritating - we'd have given you so much a faster answer if we'd know you have a SCPF in the first place. Please consider the volunteers time when asking for assistance and what might be a material information. In that respect, any recommendations about which way to go aren't likely to be forthcoming because we don't know what you are hoping to build! Step back from your keyboard and think, I want to achieve X, if was answering the question, what information would I need to be able to provide a decent answer. |
Beta Was this translation helpful? Give feedback.
-
|
@HeadBoffin thank you for answer! First of all - sure I know - "A question asked correctly is half the answer." ) Almost all tech details about "what I want to achieve" explained here Anyway - Im really appreciate such a full explaining of the situation with single packet forwarder. The one thing Im also not sure - if I can send downlink messages to particular Nodes in my LoRaWAN network.. |
Beta Was this translation helpful? Give feedback.
-
I decided to create new discussion because it related to LoRaWAN.
Though I asked similar question about Cubecell here - it is just about example for simple LoRa.
So - I've read LoRaWAN Notes -
And I so far checked two examples - LoRaWAN_Starter.ino and LoRaWAN_ABP.ino
Also I added two Devices into my TTN account and uses their KEY's* and ID's* for config.h and configABP.h
All settings in config's files corresponding to their settings for TTN Devices:
I will show details about LoRaWAN_ABP example to not double information in this question, but for LoRaWAN_Starter variant Im also did the same necessary configuration settings.
configABP.h for LoRaWAN_ABP.ino
in the main program I just changed one line:
int16_t state = radio.begin(868.0, 125.0, 9, 5, 0x34, 10, 8, 1.6, false);and finally - CubeCell terminal shows:
I can see these signal via my SDR which means that my CubeCell works, at least it sends radio signals:
But my Gateway doesnt show any activity in these moments and TTN also shows "Last activity" == Never for Device..
My current question only about CubeCell side - Is it possible that I did something wrong in code for CubeCell?
How to use these examples for CubeCell's and EU868 in correct way?
Beta Was this translation helpful? Give feedback.
All reactions