SkyView AMOLED round 1.75 for Waveshare board

[Antoine Megens]

Hi Y'All,

I've completed the port of SkyView firmware for the Waveshare AMOLED 1.75 round board.

I've just made the first release available on github:

https://github.com/dingetje/SkyView-AMOLED-round-1.75-TFT_eSPI

In addition to the LilyGo version, this board offers Audio output, so I've added voice output.

https://www.youtube.com/watch?v=eLwic-Sz4lM

I've also added support for the OGN database on the SD card. When enabled in Settings, the Status page shows how many OGN records are loaded.

I've not yet tested this feature in the field, so there may be some bugs still in it.

The board requires more power than the LilyGo (~180mA vs ~120mA) but I've tested with a  3.7V/1100mAh Lipo battery, and this seems sufficient for 6+ hours.

TODO: a 3D casing for this board.

Regards,

Antoine

[Vlad Belayev]

Hi Antoine,

Great work—thanks for sharing your GitHub repo. I had a quick look and saw you've integrated both LilyGo and Waveshare versions into the same codebase, with conditional builds in platformio.ini. Smart approach—I had the same idea.

I just received the Waveshare 1.75" AMOLED and started working with it. Audio sounds good, though the included speaker is quite large. I’m using a smaller 20×14×4 mm side-ported speaker that fits better in the round case and still delivers loud output.

Power draw at ~180 mA is hefty. LilyGo typically runs at 90–100 mA. My original 3D case was designed for a 600 mAh (503040) battery, giving ~4–4.5 hours of flight time. It fits the round shape well, but I’m now designing a version for two stacked 600 mAh batteries and adding a battery isolator switch to prevent drain during sleep mode.

The upcoming LilyGo 1.75" AMOLED version will support the MAX98357 I2S audio board, which fits the same case—bringing it in line with the Waveshare setup. I’ll upload the case design to GitHub once it’s ready.

Currently facing an SD card issue: SPI mode on LilyGo seems to slow down the display. I assume Waveshare avoids this with its MMC library.

Loading the OGN database sounds promising. I previously experimented with Puretrack DB via SQLite3 but didn’t find a clear benefit, so I dropped it

I friend of mine also working on a 3D case for 1150mA battery, it would probably suit you better,
 It is still work in progress and would look something like this.

[Antoine Megens]

I've done a few more measurements and the ~180mA power consumption is with WiFi UDP as data source.

I've just added a call to disable the Analog Power Bus, this does not seem to affect the Audio output and will save ~10mA for the not used ES7210 chip (for the two microphones on the Waveshare board).

In addition with the WiFi Power Save option enabled (disable WiFi after 5 minutes) and BLE data source, the power consumption dropped to ~130-140 mA.

Also, I forgot to mention, I've written a small Windows console tool for test purposes that can feed an NMEA test file via UDP to the SkyView:

https://github.com/dingetje/SkyView-AMOLED-round-1.75-TFT_eSPI/tree/main/tools

Cheers!

Antoine

Op vrijdag 26 september 2025 om 00:03:18 UTC+2 schreef Vlad Belayev:

[Antoine Megens]

Unfortunately that 130-140mA was measured without an active BLE connection. The power usage goes back up to around 170mA when the board has an active BLE NMEA data stream coming in.

Op vrijdag 26 september 2025 om 15:00:59 UTC+2 schreef Antoine Megens:

[Vlad Belayev]

Oh ok, strange. WiFi UDP would be understandably higher consumption , but BLE is strange. Especially NimBLE suppose to be lower.
I will do more measurements on LilyGo board with and without BLE and compare.
It is sometimes hard to tell what exactly draws more power. 
So I did a test , by staggering the initialisation of each component by 10 seconds and then setting the stopwatch. It seemed the biggest jump was around initilising SPI and display by about 60mA. 
Waveshare has more components and a few ADC's. ADC 's could be drawing some, so may be worth disabling if not used for battery check.

[Antoine Megens]

I had a limited amount of time to test my new firmware for the waveshare board yesterday in the field.

I managed to establish a BLE connection to a PowerMouse+, albeit I needed to repeat the scanning procedure a couple of times before the device was detected.

I had not laptop with me, so couldn't check the Serial debug output. I may add logging to SD for debug purposes.

This test showed that the traffic advisories voice output worked, but it may be a bit too much with over 6 planes on the radar (my plane was stationary on the starting grid and those other planes were close to the airfield).

Currently voice output is either on or off, but maybe a setting should be added to allow "danger" reporting only?

While the OGN db was loaded correctly, it isn't used in the Text View page (probably in favor of the BuddyList).

I've modified the code to give the buddylist priority, but if not found there, attempt the OGN db and use that data.

I've added a test query in my startup code, and the OGN loading and query code works as expected.

So yeah, work to be done!

Regards,

Antoine

Op zaterdag 27 september 2025 om 00:20:44 UTC+2 schreef Vlad Belayev:

[Vlad Belayev]

I am also still having issues connecting BLE to SoftRF devices (tried a few). The debug says Scanning.. then found 0 devices. although they are near.
There is filter to show only service "ffe0" devices, but that comes in after devices found. Not sure what it is yet. On LilyGo board the same code finds devices perfectly.

Indeed, currently Voice is either On or Off. Could change to Options in the drop down list as "Traffic Advisories and Collision alerts",
"Collisions Alerts only ", "OFF".
There is also a request to make SkyView to accept $PFLAA/$PFLAU levels as alert triggers.
Does PowerMouse provide such levels?

Including, OGN db in the Radar and  Info page is a good idea, indeed previously it as only set to show buddy from the list.
I was just thinking also a third option for ADS-B traffic to show airplane Call Sign in the name text field. (if no values found in BuddyList or OGN)
CallSign is transmitted in ADS-B message , so no extra db needed.

 While we are on this topic of OGN, I read earlier that FLARM dataport supports transmitting aircraft registration and even pilot name via $PFLAM? This is a question on SoftRF , is that possible to implement to receive and decode it? So eventually there will be no need for OGN db? 

https://www.flarm.com/wp-content/uploads/2024/12/FTD-109-FLARM-Messaging-Interface-Control-Document-v1.00.pdf

[Kevin Wilson]

Regarding

“There is also a request to make SkyView to accept $PFLAA/$PFLAU levels as alert triggers.
Does PowerMouse provide such levels?”

The Skyview display will work with any Flarm that has its ports correctly configured to send the $PFLAU and $PFLAA sentences. These are the sentences any Flarm display need to show traffic and alerts. So yes will work with PowerMouse.

If connecting by cable, note Flarm output via RJ45 is RS232 signal which needs to be converted to Skyview TTL signal. Some PowerMouse devices have Bluetooth data out.

Skyview code (NMEAHelper.cpp)already does parse $PFLAA/$PFLAU sentences and saves them as alarm levels as T_AlarmLevel ($PFLAA) and S_alarmLevel ($PFLAU). Traffic data is added or updated in the ‘container’ for traffic found.

What the Skyview does with the alarms depends on which branch of Skyview code you are using. My version WAGA Skyview is different to Moshe’s in the presentation of the alarms. Eg I added the concept of threat and a relative bearing indicator that points to the threat.

Kevin Wilson


Sent from my iPhone

[Antoine Megens]

Yes, PowerMouse provides such alarm levels, any FLARM device should since these are the same sentences that drive the classic FLARM displays and Butterfly displays.

I've yet to see a $PFLAM sentence, but it sure looks like a promising extension. For classic flarms the feature is quite limited though.

It looks like the feature also supports active queries, so SkyView could request this data.

I have access to a PowerFlarm Fusion and will give this a try.

Here's a screenshot with the OGN call sign added when labels are enabled in the settings page.

Default SkyView showed only the relative height (+50m), but now, when the device ID is found in OGN, the call sign is added too.

Regards,

Antoine

Op ma 29 sep 2025 om 23:17 schreef Vlad Belayev <vlad.b...@gmail.com>:

--
You received this message because you are subscribed to a topic in the Google Groups "SoftRF_community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/softrf_community/BolV--nmknQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to softrf_communi...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/softrf_community/665820f2-95c6-44de-8820-439c3a3c0925n%40googlegroups.com.

[Antoine Megens]

Ok, I've tried the $PFLAM sentence with a PowerFLarm FUSION and the only command that is accepted is:

$PFLAM,R

this requests the messaging queue status and the response is something like:

$PFLAM,R,<Queued>,<Sent>,<QueueCapacity>*CS

It seems this messaging system is designed to sent out and receive data between FLARM devices and ground equipment autonomously over the RF channel only and it's not possible to inject this via the data port.

What this means is that the local NMEA stream will echo received data from other flarms using the $PFLAM sentence, but there's not a command possible to query this data on request.

So, I think, yes, SkyView can add support for this sentence. 

Keep in mind that only the most basic data (PNAME, ATYPE, AREG and ACALL) is supported without a license and that this data is hex encoded UTF-8 data.

This feature could indeed resolve the need for a centralized FlarmNet or OGN database, but it requires correctly configured FLARM devices and we all know that this is not always the case.

Op dinsdag 30 september 2025 om 11:26:49 UTC+2 schreef Antoine Megens:

[Antoine Megens]

BTW, I found the issue with the BLE scanner, the scan duration was set to only 3 ms, incremental. This may have been enough for the LilyGo board but didn't work well on the Waveshare board.

I've increased the scan time to 500ms and now my SoftRF T-beam is found right away.

Op dinsdag 30 september 2025 om 18:02:53 UTC+2 schreef Antoine Megens:

[Vlad Belayev]

Ha, that's interesting. 

I though the response "Not found" came rather quick.

I was under the impression that it was in seconds,  as Intelisense suggest this time is in seconds.

I tied increasing to 5. Clearly that wasn't enough. 

So if 500 works and it's not hanging , that's good. I will follow up later.

[Vlad Belayev]

Thanks for investigating  $PFLAM, this is useful insight. 

IThis implementation looks similar to FANET messaging and weather reporting. 

I though its about time FLARM implemented it.

Ofcoarse it will take time for adoption of adding name and Reg on the devices.

Similar to paragliding FANET devices. But nowadays everyone hase name programmed in, as its part of the initial setup of the device.

No REG in PG of course. 

Another useful trick is it can be set to Nickname + radio frequency.  So if one wants to communicate to you,  that's the freq to reach you on.

Secondly, $PFLAM certainly can be added to SkyView,  at least its ready.

I can see a use for it.

But also it would benefit to add  $PFLAM to SoftRF code.

I have my branch , primarily for Card (SenseCap T1000E)

And can look into it.

I was also looking to implement a FANET beacon, whilst SoftRF is working in LATEST (LEGACY) mode.

Just to transmit a FANET packet every 4sec, plus FANET name every 39s. So it shouldn't impede the FLARM operation. 

It's a bit waht GXAIRCOMM is doing , but not to receive FANET. 

[Antoine Megens]

New release: 

https://github.com/dingetje/SkyView-AMOLED-round-1.75-Waveshare/releases/tag/WS003.A001

Op woensdag 1 oktober 2025 om 09:56:24 UTC+2 schreef Vlad Belayev: