Krakensdr is a very interesting product. But a few important things are necessary for users.
One of the confusing things is heading. Many users have asked a question about this.
All the software developers’ decisions for Raspberry Pi and Android were based on the need for a car to move. But today is the middle of 2025. GNSS models with the heading function have appeared on the market. I bought a GNSS modul UM982 and two spiral antennas GNSS HX-901 (or two spiral antennas GNSS HA-609). If these antennas are placed at a distance of 1 meter, the module is able to provide heading with very high accuracy.The UM982 module is easily configured using the PC software. I have configured NMEA output of messages like $GNRMC and messages like $GNHDT. Next, connect the UART on GPIO header inc 8/10 (GPIO 15/14) Raspberry Pi 5.
The GPSD service normally receives these messages.
So what’s the problem? Why can’t you make changes to the program to directly transfer these heading values to the web interface and to the Androin application?
P.S.: I have not activated all other messages in the UM982 module.They are not required for this experiment…
I continued experimenting, and imitated a message like $GNHDM. Again, the GPSD service receives my messages well and recognizes the magnetic track. But this data is also not transmitted to the web interface and to the Android application. This means that any magnetic compass will not work with the krakensdr. If the truth heading $GNHDT and the magnetic track $GNHDM are well received by the GPSD service, but this data is not transmitted to the web interface and to the android application, how else can this data be transmitted to the web interface and to the android application???
I’ve read all the forum posts about heading. All the recommendations and tips are something like this- we don’t know which compass to use, we’re not sure if the GPSD service will work with your GPS and your compass. Now that it is clear that the GPSD service accepts both “true heading” and “magnetic heading”, what else can be done to ensure that heading is transmitted from raspberry pi 5 ?
Yes compasses haven’t been implemented in the KrakenSDR software yet. It’s something on the todo list though. But if GPSD now natively supports compasses then this makes the job much easier.
Unfortunatley until we get to that on the list, it would be up to you to create the code to support your device.
Greetings to all kraken users. The discussion about heading and the magnetic compass is already very old. But this issue remains unresolved. So I solved this problem on my own. This is not a ready-to-use solution. I’ve never used raspberry pi before, and I’ve never written python code. Nevertheless, in two days I was able to figure it out enough to do it my way. In short, I had to programmatically replace the field in the NMEA sentence. I took the data from the “heading” field of $GNHDT (or $GNTHS), and inserted this data into the “track” field of $GNRMC. Next to the file "kraken_sdr_signal_processor.py " added two lines and changed one line. Now, using the compass described at the beginning of this topic, I get the “heading” change in the Android app. I am very pleased with the result, and now I will try to output this data to the web interface. I will also try to use $GNTHS directly without replacing fields in $GNRMC.
News No. 2
This device is very promising. And it needs to be called something on the forum. From now on, I will refer to the device as DATHFK (dual antenna true heading for kraken). This device is the most promising for heading. Magnetic compasses have many disadvantages, and I personally won’t talk about them anymore. Now, adding magnetic compass support for kraken is no longer of interest to me. I will continue to try to improve the way krakensdr works with DATHFK. As for the hardware, I’ll call it DATHFK_hard. Everything related to the software part, I will call DATHFK_soft.
P.S. If I make a mistake in something, or offer harmful advice, I ask the respected moderator to report it.
News No. 3.
Today I was working on improving DATHFK_soft. My concept is to completely abandon the “track” when the car is moving and use only True Heading. Now, regardless of the movement of the car, there will always be the correct heading.Today’s work on DATHFK_soft has brought the following results. True Heading is now transmitted to both the web interface and the Android app. So far, everything is working well, and no bugs have been detected (in fact, there are always bugs, maybe I’ll find them later).When I have free time, I will continue to work on DATHFK_hard and DATHFK_soft. I have a work plan for the device and possibly in the future for other additions such as “Pickle button for jammer hunting”…
No problems. I will spend more time to simplify and minimize the design. And of course, for everyone who wants to, I will give information on how to do this and publish the scheme and firmware.
