Add support to Si1060 silicon labs MCU with Transceiver #62

kaklik · 2020-10-19T19:42:27Z

The support of the new chip brings some new features and reduce external components count.

The Si1060 is much more accessible in EU for modem manufacturing than older Si102x or Si103x variants
Si1060 has slightly improved sensitivity
The new Si1060 has some more robust and modern modulation modes

Additional benefits are described in Silabs AN811

Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

This allows a GCS / or drone to actively identify if the SiK radio is capable of MAVLink 2.0.

This is a work-in-progress port to Si1060. So far, the modem only supports fixed airrate of 64 kbps with ECC and manchester encoding disabled, but within those contraints, it appears on-air compatible with Si443x version of the firmware. Some other features, like RSSI or temperature readout, are also missing.

Changes include adding support for all the air rates, frequency hopping and ECC. Also supported are both the 433 and 868 mhz bands, although only 433 was tested.

Add the link to new supported MLAB modem.

It appears the TX_FIFO_ALMOST_EMPTY flag in PH_STATUS register is an unreliable indicator of being able to insert more bytes into the fifo. Relying on the space returned by the FIFO_INFO command instead fixes fifo underflow/overflow errors previously observed while transmitting long packets.

Initializing at_mode_active at the variable declaration did not have the effect. Strange.

tridge · 2021-04-25T00:13:53Z

where do I get a radio with a Si1060 for testing?

Fix issue ArduPilot#65

Enhance AT commands table layout.

tridge · 2021-06-02T04:13:01Z

I had some build errors which I fixed here:
https://github.com/ArduPilot/SiK/tree/Si1060
with those changes this PR builds with sdcc 4.0.0, but the resulting firmware on old SiK is unreliable. It loses about 80% of packets where there is no packet loss with the current release firmware

tridge · 2021-06-02T04:34:29Z

if I build with sdcc 3.1.0 then it runs fine, but the radio_446x code doesn't build

povik · 2021-06-02T18:35:42Z

Hi @tridge,

I am the original author of the changes to support Si1060 that are included with this PR. As I don't see this mentioned, please note that the PR also includes changes pulled from LorenzMeier's repo which are related to MAVLink 2.0 heartbeats. There's a branch with Si1060 support kept without other changes here.

Regarding the build errors, this is how I have been building the firmware to get it to compile under sdcc 4.0:

CFLAGS="--disable-warning 158 --disable-warning 230 --disable-warning 126" make install~radio~ism01a

I haven't communicated this fact to @kaklik, so that may have caused some confusion. Nonetheless with your fixes you should have gotten the same firmware as we have been using.

Regarding the 80 % packet loss, that comes as a surprise to me. Please let me know how you are testing this and we will try to replicate.

tridge · 2021-06-09T05:50:53Z

@povik ok, we're better off using pragmas to disable those warnings.

Regarding the 80 % packet loss, that comes as a surprise to me. Please let me know how you are testing this and we will try to replicate.

I've been using two Holybro SiK radios (Si1000 based). Connected to ardupilot with mavproxy over the radios and looked at packet loss levels.

Are you on the ArduPilot discord SiK channel? Holybro is also looking at the SiK1060 and I'd like to make sure schematic choices (eg. crystal) match what you've done so we can use a common fw

kaklik · 2021-06-09T22:20:36Z

Are you on the ArduPilot discord SiK channel? Holybro is also looking at the SiK1060 and I'd like to make sure schematic choices (eg. crystal) match what you've done so we can use a common fw

Hi @tridge! Have you some control over Holybro production eg. schematics etc.? I am curious about that, because I do not see any open-source hardware from Holybro until now. In 2018 I requested at least schematics from theirs Pixhawk 4, but the sales department replied to me with a foggy and irrelevant reply "Sorry, Sir I can't provide the full schematics. But I think you can find it on PX4 website..." Therefore I am restrained to help Holybro with hardware design without symmetric behavior from their side.

tridge · 2021-06-09T22:50:28Z

I am curious about that, because I do not see any open-source hardware from Holybro until now.

a lot of their schematics are open, including Pixhawk4:
https://github.com/ArduPilot/Schematics/tree/master/Holybro
they have not given permission for me to release their radio schematic yet, but I do have permission to share it privately with you and @povik as long as you don't post it publicly.

tridge · 2021-06-09T23:41:21Z

I've done some more testing with tools/mavtester.py like this:
tools/mavtester.py --port1 /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D308L5W6-if00-port0 --port2 /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN04SBQY-if00-port0 --rate 10
I've found that if I put your fw on both radios (holybro hm-trp radios) then it performs fine, but if one radio has current release firmware and one has firmware from this PR then it gets 90% packet loss.
So we need to find what has changed to make it lose packets versus current firmware. Maybe a framing change?

these are my parameters for reference:

S0:FORMAT=26
S1:SERIAL_SPEED=57
S2:AIR_SPEED=128
S3:NETID=2628
S4:TXPOWER=20
S5:ECC=0
S6:MAVLINK=1
S7:OPPRESEND=0
S8:MIN_FREQ=915000
S9:MAX_FREQ=928000
S10:NUM_CHANNELS=20
S11:DUTY_CYCLE=100
S12:LBT_RSSI=0
S13:MANCHESTER=0
S14:RTSCTS=0
S15:MAX_WINDOW=131

povik · 2021-06-10T13:05:52Z

Thanks. Obtaining the same result with mavtester should be easy for me to do. The behavior is strange. There shouldn’t be any changes to framing apart from minuscule timing changes introduced by compiler. An idea I had is that the MAVLink reporting changes interfere with testing by injecting packets where they are not expected. Of course that does not fit with the PR firmware performing fine when talking to itself.

…

On Thu, Jun 10, 2021 at 01:41, Andrew Tridgell ***@***.***> wrote: I've done some more testing with tools/mavtester.py like this: tools/mavtester.py --port1 /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_D308L5W6-if00-port0 --port2 /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_DN04SBQY-if00-port0 --rate 10 I've found that if I put your fw on both radios (holybro hm-trp radios) then it performs fine, but if one radio has current release firmware and one has firmware from this PR then it gets 90% packet loss. So we need to find what has changed to make it lose packets versus current firmware. Maybe a framing change? — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#62 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAC5JUA2D35XSLRDEJN5KDLTR7323ANCNFSM4SWSTGHQ).

tridge · 2021-06-12T23:29:29Z

@povik the problem turns out to the the shuffing of the channels in freq_hopping.c. If I set it up with 2 channels then I get no packet loss.
I suspect a change in srand(), but I haven't proven that yet

tridge · 2021-06-13T22:44:52Z

The problem was rand(). I've fixed it here:
https://github.com/ArduPilot/SiK/tree/Si1060

tridge · 2021-07-11T23:33:05Z

@povik @kaklik I've received my development Si1060 radios from Holybro. They are 915MHz, so I'd like to add band_915_prop_vals. Can you send me the project file for the Silabs tools you used to generate the 433 and 868 config?

tridge · 2021-07-11T23:47:21Z

looks like what is missing is tools/build_si446x_table.py

povik · 2021-07-12T05:36:20Z

@tridge Sorry, that one slipped through. Here you go: ThunderFly-aerospace@42df857

As I seem to remember there's no project file to speak of on part of the Silabs' software, but I found the original exported headers. Note that I now think I probably set the channel filters too wide in those.

wds_headers.zip

tridge · 2021-07-13T06:26:00Z

Sorry, that one slipped through. Here you go: ThunderFly-aerospace@42df857

Thanks!
I've now built headers for 915, and started testing.

A few striking things:

I get a high rate of packet loss between Si1060 an Si1000 radios
I get no packet loss between two Si1000 radios, even if one is running the old code and the other the Si1060 branch
I get high packet loss between two Si1060 radios
the reported RSSI level on Si1060 radios is much lower (I suspect a scaling issue)

For the packet loss I'm testing with tools/mavtester.py. Have you tried mavtester with your 433 or 868 radios? Do you get zero packet loss at short range? Note the branch I'm using is this one: https://github.com/ArduPilot/SiK/tree/Si1060

tridge · 2021-07-13T08:07:42Z

the problem seems to be more with packet receive than with send. Packet send seems quite reliable. That makes me think perhaps a problem with the preamble detection?

povik · 2021-07-13T09:09:53Z

I don’t have the time right now to run the tests, but Friday I can reserve some time for this. Have you ruled out the issue to be related to frequency hopping? Do you see it with one channel settings?

…

On Tue, Jul 13, 2021 at 10:07, Andrew Tridgell ***@***.***> wrote: the problem seems to be more with packet receive than with send. Packet send seems quite reliable. That makes me think perhaps a problem with the preamble detection? — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#62 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAC5JUGT2H4FVL7F2HSQKMDTXPX5TANCNFSM4SWSTGHQ).

tridge · 2021-07-14T21:16:46Z

Have you ruled out the issue to be related to frequency hopping? Do you see it with one channel settings?

yes, I've ruled that out. Note especially that there is no problem with the Si1060 branch run on a Si1000 radio, so we know that the issue must be in the Si1060 specific part of the code.

povik · 2021-07-14T22:13:14Z

Right, I just remember that the channel changing on Si1060 during receival is a bit tricky and I could picture it breaking when on an untested band. Anyway I will get back to you on Friday with mavtester results. (It will be with 433 radios.)

…

On Wed, Jul 14, 2021 at 23:16, Andrew Tridgell ***@***.***> wrote: > Have you ruled out the issue to be related to frequency hopping? Do you see it with one channel settings? yes, I've ruled that out. Note especially that there is no problem with the Si1060 branch run on a Si1000 radio, so we know that the issue must be in the Si1060 specific part of the code. — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#62 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAC5JUHDFRI4UYY76O3JAFTTXX5ERANCNFSM4SWSTGHQ).

tridge · 2021-07-15T08:04:52Z

Anyway I will get back to you on Friday with mavtester results. (It will be with 433 radios.)

thanks!

povik · 2021-07-16T20:48:58Z

So yes, mavtester does report non-zero packet loss between two 433 Si1060 radios. (Settings were default, firmware I tried both your branch and thunderfly/si1060-wip.)

$ tools/mavtester.py --port1=/dev/ttyUSB0 --port2=/dev/ttyUSB1
...
Lost 3 GLOBAL_POSITION_INT messages
Veh:2312/198/65  GCS:68/1971/1939  pend:373 rates:43/2000 lat:47/210/124 bad:17/128 txbuf:83/100 loss:348:15%/1:1% fixed:0/0
Veh:2380/205/68  GCS:70/2040/2007  pend:373 rates:43/2000 lat:47/210/121 bad:17/128 txbuf:91/100 loss:348:14%/1:1% fixed:0/0
Veh:2448/210/69  GCS:72/2093/2059  pend:389 rates:43/2000 lat:47/210/121 bad:17/128 txbuf:86/100 loss:364:15%/1:1% fixed:0/0

$ tools/mavtester.py --port1=/dev/ttyUSB0 --port2=/dev/ttyUSB1 --mav20
...
Veh:3315/291/96  GCS:98/3281/3233  pend:82 rates:48/2264 lat:53/245/131 bad:0/312 txbuf:84/100 loss:82:2%/0:0% fixed:0/0
Veh:3383/297/98  GCS:100/3348/3299  pend:84 rates:48/2264 lat:53/245/129 bad:0/366 txbuf:81/100 loss:84:2%/0:0% fixed:0/0
Veh:3451/303/100  GCS:102/3417/3367  pend:84 rates:48/2264 lat:53/245/131 bad:0/366 txbuf:93/100 loss:84:2%/0:0% fixed:0/0

tridge · 2021-08-21T06:46:01Z

@povik have you compared the receive sensitivity of your 1060 radios to an equivalent Si1000 radio such as the Holybro SiK radio? I've gotten the packet loss down a bit, but the receiver sensitivity is still awful. It is about 35dB lower than an equivalent Si1000 radio.
I've confirmed this value in two ways:

the reported RSSI
using a 30dB attenuator inline with an antenna and testing at a known distance

tridge · 2021-08-29T00:53:32Z

@povik I worked out the issue, the holybro radio uses different GPIO_0/GPIO_1 settings for the RF switch. I've also work out what causes most of the packet loss and have fixed that. Updated version in
https://github.com/ArduPilot/SiK/tree/Si1060

tridge · 2021-09-14T04:58:59Z

I have merged Si1060 support to master based on my branch. Many thanks for your contribution!

patrickelectric and others added 15 commits July 30, 2017 02:20

Solve error, add break after default

a5ec570

Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>

Detect protocol version and MAVLink 2.0 heartbeats and respond in 2.0

bd43a9f

This allows a GCS / or drone to actively identify if the SiK radio is capable of MAVLink 2.0.

Mac OS: Ignore metadata files

27fcdf5

ec2 tools link updated to better maitained fork.

32622ac

Fix build

23292e1

Progress on port to Si1060

8c5a410

Changes include adding support for all the air rates, frequency hopping and ECC. Also supported are both the 433 and 868 mhz bands, although only 433 was tested.

Update README.markdown

2d4f429

Add the link to new supported MLAB modem.

Merge branch 'si1060-wip' into si1060-mavlink2

3a5c389

New script for modem parameters reset.

4e4e14a

Disable AT mode after reset

938af68

Initializing at_mode_active at the variable declaration did not have the effect. Strange.

Merge branch 'si1060-wip' into si1060-mavlink2

0e0f80a

Merge remote-tracking branch 'origin/si1060-mavlink2'

85d8725

Update README.markdown

0b9693f

kaklik added 4 commits May 15, 2021 10:47

Improve documentation section

0676009

Fix issue ArduPilot#65

Readme improvement. AT commands table.

4228d74

Update README.markdown

6360667

Update README.markdown

a163a61

Enhance AT commands table layout.

Update uploader.py - adding an exaple of the usage

57591b1

tridge closed this Sep 14, 2021

kaklik mentioned this pull request Oct 20, 2021

Suspicious packet loss between Holybro and TFMODEM ThunderFly-aerospace/SiK#7

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support to Si1060 silicon labs MCU with Transceiver #62

Add support to Si1060 silicon labs MCU with Transceiver #62

kaklik commented Oct 19, 2020 •

edited

Loading

tridge commented Apr 25, 2021

tridge commented Jun 2, 2021

tridge commented Jun 2, 2021

povik commented Jun 2, 2021 •

edited

Loading

tridge commented Jun 9, 2021

kaklik commented Jun 9, 2021

tridge commented Jun 9, 2021

tridge commented Jun 9, 2021 •

edited

Loading

povik commented Jun 10, 2021 via email

tridge commented Jun 12, 2021

tridge commented Jun 13, 2021

tridge commented Jul 11, 2021

tridge commented Jul 11, 2021

povik commented Jul 12, 2021

tridge commented Jul 13, 2021

tridge commented Jul 13, 2021

povik commented Jul 13, 2021 via email

tridge commented Jul 14, 2021

povik commented Jul 14, 2021 via email

tridge commented Jul 15, 2021

povik commented Jul 16, 2021

tridge commented Aug 21, 2021

tridge commented Aug 29, 2021

tridge commented Sep 14, 2021

Add support to Si1060 silicon labs MCU with Transceiver #62

Add support to Si1060 silicon labs MCU with Transceiver #62

Conversation

kaklik commented Oct 19, 2020 • edited Loading

tridge commented Apr 25, 2021

tridge commented Jun 2, 2021

tridge commented Jun 2, 2021

povik commented Jun 2, 2021 • edited Loading

tridge commented Jun 9, 2021

kaklik commented Jun 9, 2021

tridge commented Jun 9, 2021

tridge commented Jun 9, 2021 • edited Loading

povik commented Jun 10, 2021 via email

tridge commented Jun 12, 2021

tridge commented Jun 13, 2021

tridge commented Jul 11, 2021

tridge commented Jul 11, 2021

povik commented Jul 12, 2021

tridge commented Jul 13, 2021

tridge commented Jul 13, 2021

povik commented Jul 13, 2021 via email

tridge commented Jul 14, 2021

povik commented Jul 14, 2021 via email

tridge commented Jul 15, 2021

povik commented Jul 16, 2021

tridge commented Aug 21, 2021

tridge commented Aug 29, 2021

tridge commented Sep 14, 2021

kaklik commented Oct 19, 2020 •

edited

Loading

povik commented Jun 2, 2021 •

edited

Loading

tridge commented Jun 9, 2021 •

edited

Loading