Последние сообщения

1

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« Последний ответ от старый32123 Сегодня в 13:30:58 »

спасибо вам за всю эту тему, сам вчера пытался с этим всем разобрать вникал и пробовал
но всё же хотелось бы узнать
а есть ли прошивка где всё настроенное и тому подобное? 

2

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« Последний ответ от Sonja-K2SMT Вчера в 21:54:30 »

I didn't think of that approach, thanks!!!

Using a Baofeng with custom OpenDM32 firmware, I was able to view raw NMEA packets from the GPS module. The transceiver was near a window, and the satellite level and number were low. As you can see, the deviation is quite large, requiring software filtering.

Yes, I concur. The deviation I've been experiencing is quite large. I've seen fixes that were nearly a quarter mile away.

I implemented some filtering on the Map Display page I'm working on, and it corrected much of the drift. There is still drift, but it is much tighter. As you would expect with higher-end GPS hardware, it is now within about 20 feet or so.

The Leaflet map does not zoom in closer than, I'd guess, about 500–750 feet, so you now just get a blue blob representing the drift. I think I introduced a bug on the page while doing some other unrelated work, and my history trail isn't displaying, or I'd have a screenshot to share showing the difference. Once I track down that bug, I'll have some comparison images to post. I'll also try to summarize the filtering code so I can share what was done to tighten the displayed drift.

I should note that the code does not fix the drift on the radio itself—it only tightens the displayed fixes on the back-end map. So it's more of a workaround band-aid than a true GPS drift solution for the radio. The radio's GPS is still sending wildly divergent fixes, but now the map averages the fixes over a time limit and a speed factor (less than 2 mph) to clean up the trail display.

As I said, I have a bug somewhere that killed my history trail function, and I'm still having issues sending fixes upstream from the hotspot to the backend server when they are not on the same LAN. I'm considering implementing a VPN between all the components. This could also strengthen data security between them over the internet.

I'm just not sure how well the Pi Zero W will handle running a VPN, SQLite, and the normal hotspot functions at the same time. I'm planning to pick up a Pi Zero 2 W soon and give it a try on better hardware. My goal hardware for the final project would be a Pi 5, but I have to work with what I have for now due to a tight budget.

3

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« Последний ответ от Koshak Вчера в 10:49:52 »

I didn't think of that approach, thanks!!!

Using a Baofeng with custom OpenDM32 firmware, I was able to view raw NMEA packets from the GPS module. The transceiver was near a window, and the satellite level and number were low. As you can see, the deviation is quite large, requiring software filtering.

4

Трансиверы, приемники КВ/УКВ / Re: OpenDM-32

« Последний ответ от Koshak 05 Марта 2026, 18:18:24 »

Плагин для импорта карты памяти HR_C7000 в Ghidra
Спасибо jv666

5

Трансиверы, приемники КВ/УКВ / Re: OpenDM-32

« Последний ответ от Koshak 05 Марта 2026, 18:03:37 »

https://github.com/SarahRoseLives/dm-32uv

Спасибо, как я понял команды PCTESTM, DEL-RCD, IDCHECK до сих пор не изучены 

6

Трансиверы, приемники КВ/УКВ / Re: OpenDM-32

« Последний ответ от Chrystian 05 Марта 2026, 03:54:02 »

карта памяти

https://github.com/SarahRoseLives/dm-32uv

7

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« Последний ответ от Sonja-K2SMT 04 Марта 2026, 23:17:08 »

Are there tuning values in the firmware that can tighten the drift, or does it simply come down to the hardware being the determining factor?

The coordinate deviation is most likely due to the lack of a filtering and data averaging algorithm. This effect is evident in many GPS receivers.

OK, so if there is nothing firmware wise that can be done, then I can create some filtering logic within my page code to help refine the drift seen on the map? I didn't think of that approach, thanks!!!   

8

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« Последний ответ от Koshak 04 Марта 2026, 17:32:03 »

Are there tuning values in the firmware that can tighten the drift, or does it simply come down to the hardware being the determining factor?

The coordinate deviation is most likely due to the lack of a filtering and data averaging algorithm. This effect is evident in many GPS receivers.

9

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« Последний ответ от Sonja-K2SMT 04 Марта 2026, 06:15:18 »

Sorry for the double post, but this is an unrelated question from my last post.

Attached is a snippet from my Leaflet map where I am collecting GPS data from my DM32s.

I have not left my apartment in almost 48 hours. I have been steadily working on my backend code. But you can see the GPS drift is off the wall.

This is across about 150 points over a 24 hour period. The radio has not really moved more than a few feet in the room. It is a ground floor apartment in a three story building, and I am about six feet from the exterior wall. There is still no clear view of the sky, so some drift is expected. But seeing myself drift wildly across possibly 10 acres, with one point nearly a quarter mile away, seems excessive.

Is this purely a hardware issue combined with the obstructed view of the sky? Our phones do not even show that much drift, usually staying within a few yards. I assume a lot of it has to do with lower end GPS hardware compared to a flagship smartphone.

Are there tuning values in the firmware that can tighten the drift, or does it simply come down to the hardware being the determining factor?

10

Трансиверы, приемники КВ/УКВ / Re: Baofeng DM-32

« Последний ответ от Sonja-K2SMT 04 Марта 2026, 05:57:32 »

What other changes are in the firmware? Is there a full changelog running about?

I publish any modifications of this transceiver on this forum, I do not keep a log of changes...

Reading through 42 pages, it seems a lot of the work is inherently trial and error, which is the nature of reverse engineering. The only real roadblock is the language barrier. The built-in browser translate does help, but in Edge I have to translate each page load, and as usual a lot can be lost in translation, especially technical terms and jargon.

If you keep a repo, you could use an AI (Codex, Claude) to scan your Git tree and automatically build a CHANGELOG.md. I do that myself. For the most part it works, at least as I go. I have never tried it on a past project though. Almost afraid to, lol.

Looking forward to the changes and expansion in your firmware. It seems like a heck of a task, possibly destructive to the "donor radio". Mad Scientist Mode activated.   

 It is nice to see things Baofeng left out, or were too disinterested to build into the stock firmware.