Closed MartinPolytech closed 3 years ago
Hi, What's the serial number of that HackRF device? Are you sure that you configured the SDR block properly? Because the signal in the waterfall and in the fft it doesn't look like LoRa. Can you share the settings? --Ritam
Thank you for the quick answer.
When we use the "SoapySDRUtil --probe="driver=hackrf" command this is what we get in the terminal :
######################################################
## Soapy SDR -- the SDR abstraction library ##
######################################################
Probe device driver=hackrf
[INFO] Opening HackRF One #0 88869dc3352821b...
----------------------------------------------------
-- Device identification
----------------------------------------------------
driver=HackRF
hardware=HackRF One
clock source=internal
part id=a000cb3c006a4767
serial=0000000000000000088869dc3352821b
version=2017.02.1
----------------------------------------------------
-- Peripheral summary
----------------------------------------------------
Channels: 1 Rx, 1 Tx
Timestamps: NO
Other Settings:
* Antenna Bias - Antenna port power control.
[key=bias_tx, default=false, type=bool]
----------------------------------------------------
-- RX Channel 0
----------------------------------------------------
Full-duplex: NO
Supports AGC: NO
Stream formats: CS8, CS16, CF32, CF64
Native format: CS8 [full-scale=128]
Stream args:
* Buffer Count - Number of buffers per read.
[key=buffers, units=buffers, default=15, type=int]
Antennas: TX/RX
Full gain range: [0, 116] dB
LNA gain range: [0, 40, 8] dB
AMP gain range: [0, 14, 14] dB
VGA gain range: [0, 62, 2] dB
Full freq range: [0, 7250] MHz
RF freq range: [0, 7250] MHz
Sample rates: 1, 2, 3, 4, 5, ..., 16, 17, 18, 19, 20 MSps
Filter bandwidths: 1.75, 2.5, 3.5, 5, 5.5, ..., 14, 15, 20, 24, 28 MHz
----------------------------------------------------
-- TX Channel 0
----------------------------------------------------
Full-duplex: NO
Supports AGC: NO
Stream formats: CS8, CS16, CF32, CF64
Native format: CS8 [full-scale=128]
Stream args:
* Buffer Count - Number of buffers per read.
[key=buffers, units=buffers, default=15, type=int]
Antennas: TX/RX
Full gain range: [0, 61] dB
VGA gain range: [0, 47, 1] dB
AMP gain range: [0, 14, 14] dB
Full freq range: [0, 7250] MHz
RF freq range: [0, 7250] MHz
Sample rates: 1, 2, 3, 4, 5, ..., 16, 17, 18, 19, 20 MSps
Filter bandwidths: 1.75, 2.5, 3.5, 5, 5.5, ..., 14, 15, 20, 24, 28 MHz
These 2 images are our Soapy config for hackrf :
Our software to transmit Lora signals is this one :
#include <SPI.h>
#include <LoRa.h>
#define SCK 5 // GPIO5 -- SX127x's SCK
#define MISO 19 // GPIO19 -- SX127x's MISO
#define MOSI 27 // GPIO27 -- SX127x's MOSI
#define SS 18 // GPIO18 -- SX127x's CS
#define RST 14 // GPIO14 -- SX127x's RESET
#define DI0 26 // GPIO26 -- SX127x's IRQ(Interrupt Request)
#define freq 434E6
#define sf 8
#define sb 125E3 //125e3 -- Attention max 500e3 sur le sujet Lab7 Lora
//Affichage OLED
#include <U8x8lib.h>
U8X8_SSD1306_128X64_NONAME_SW_I2C u8x8(15, 4, 16); // clock, data, reset
int counter = 0;
void setup() {
Serial.begin(9600);
//while (!Serial);
u8x8.begin(); // initialize OLED
u8x8.setFont(u8x8_font_chroma48medium8_r);
pinMode(DI0, INPUT); // signal interrupt
SPI.begin(SCK, MISO, MOSI, SS);
LoRa.setPins(SS, RST, DI0);
Serial.println("LoRa Sender");
if (!LoRa.begin(freq)) {
Serial.println("Starting LoRa failed!");
while (1);
}
LoRa.setSpreadingFactor(sf);
LoRa.setSignalBandwidth(sb);
}
void loop() {
Serial.print("Sending packet: ");
Serial.println(counter);
// send packet
LoRa.beginPacket();
LoRa.print("hello ");
LoRa.print(counter);
LoRa.endPacket();
counter++;
delay(5000);
}
Martin
It seems your host is unable to process the samples in time. Please see https://github.com/rpp0/gr-lora/wiki/Common-compile-and-runtime-errors#gnu-radio-overflow-errors-at-runtime and https://github.com/pothosware/SoapySDR/wiki/StreamStatusIndicators for more information.
Hello !
Thanks for the quick answer once again :)
We tried to use one of the sample file test but we still can't manage to decode the signal with the lora receiver block.
As you can see below, nothing is decoded in the GNU radio console :
This is what we got for the fft and waterfall sink this time :
Do you have any idea to fix the Lora Receiver block or this is stil our nvidia card which is not powerfull enought ?
Martin
Do you have any idea to fix the Lora Receiver block or this is stil our nvidia card which is not powerfull enought ?
- I don't see an issue with the LoRa Receiver block currently. Now you are trying to decode a 10 MS/s signal while the LoRa Receiver block is configured to expect a 1 MS/s signal. It should work if you configure the block correctly.
gr-lora
does not use GPU hardware acceleration, so it's your CPU that should be powerful enough to process samples in real time. In this case however, you're reading from file so processing power doesn't matter.
Hello @MartinPolytech I see you have a 2 MHz difference between center frequency and channel list. Could you please make them same? And try again? gr-lora center frequency and HackRF center frequency supposed to be same, also make the sample rate 1M. Please apply those changes and see if you have any better result or not. Good Luck!!
Thanks you for the help both of you, unfortunately we don't have the HW anymore. Our course project has ended last week, we wouldn't be able to make the changes.
But really thanks for the help ! :D
Hello,
We tried capturing and decoding a LoRa signal with the block LoRa receiver but we are not able to see the LoRa packets in the GNU Radio console. The flowgraph we tried executing is the following :
Our Lora modem is configured to work at 434e6 (spring antenna), we set up the sf factor to 8 and the sb factor to 125 kHz.
As you can see bellow, in the fft and the waterfall sink, the Lora signals seems to be well-received :
But we can't manage to decode the signal to get our message. This is what we get in the console :
Do you know how we can fix this issue ?
Have a good day :)