search

Lora-net / sx1302_hal

SX1302/SX1303 Hardware Abstraction Layer and Tools (packet forwarder...)
Other
219 stars 272 forks source link

Why mix code from different reference designs? #28

Closed wong-hao closed 3 years ago

wong-hao commented 3 years ago

For example, the 1.0.5 version code can be used normally on my device, but the latest 2.0.1 can't work because there are more non-existent devices such as sx1261 and ADC ad338r. If I want to use the code, I can only check the previous code version.

Even if I want to use the latest version of the code to enjoy some new features by commenting out the code that calls these devices, it is very hard.

All in all, the code has no downward compatibility.

mcoracin commented 3 years ago

If you had a device which was working with the v1.0.5, it can work with the v2.0.1 too. The AD338R is only enabled if full-duplex is enabled. If full-duplex is disabled, it won't try to initialize it, so no problem. Same for sx1261, if you don't have this extra radio on your design, just leave lbt and spectral scan disabled, and no problem either.

Which gateway design are you using ? What problem do you see when running the v2.0.1 ?

wong-hao commented 3 years ago

I am using the design Semtech SX1302CxxxGW1

An error occurred when I started the packet forwarder: QQ截图20201223223758

The configuration file I'm using is almost exactly the same as the default file global_conf.json.sx1250.CN490 provided, and I don't think it's possible to make it work by disabling more options rather than adjusting the code: QQ截图20201223223929

mcoracin commented 3 years ago

Ok, we'll have a look into this when we'll be back from christmas holidays, beginning of january. This board has not been tested with this release, so there is maybe an issue. But we'll fix it.

wong-hao commented 3 years ago

My fault, because there is no temperature sensor (I2C device) in my design, I need to comment out some 'I2C field'-related code. Version 2.0.1 needs to comment more of these code according to my own judgment, so there was an error before.

It would be great if there is an option like full-duplex and lbt to choose whether to enable the I2C devices such as temperature sensor and analog device. After all, GPS function can be selected to enable or not, So temperature is not a data that must be collected. Of course, I just make an opinion.

mcoracin commented 3 years ago

Hello, Do you mean that the radio setup error you were getting was due to I2C ?

wong-hao commented 3 years ago

Hello, Do you mean that the radio setup error you were getting was due to I2C ?

The main reason is that I didn't have the I2C device. Later, I commented out the relevant code in the file and it can run successfully

mcoracin commented 3 years ago

But I still don't understand why having no temperature sensor lead you to get the SX1250 setup error you shown in your comment https://github.com/Lora-net/sx1302_hal/issues/28#issuecomment-750330581

If no temperature sensor is found, you should get the corresponding error from here: https://github.com/Lora-net/sx1302_hal/blob/05416800cd3f3681db49201fe4335835ef91c1a2/libloragw/src/loragw_hal.c#L1110

Could you explain what you changed exactly ?

wong-hao commented 3 years ago

Well, this error is caused by the hardware manufacturer I bought So I can't explain why it reports it.

What I mean is that the gateway can work normally means that after reporting this error once, there is no such error for the second time.

When the code is not commented out, the gateway can't work means it always reporting this error.

But I still hope that there is an option to enable the I2C in global.config to avoid this problem.

mcoracin commented 3 years ago

The Corecell reference design includes a temperature sensor in order to compensate the temperature impact on the reported RSSI. So for now, we expect the gateway to have a temperature sensor, in order to be precise with the RSSI reported.