https://www.crowdsupply.com/krakenrf/krakensdr/updates/holiday-season-update [Holiday Season Update](https://www.crowdsupply.com/krakenrf/krakensdr/updates/holiday-season-update) byKrakenRF Inc [View previous update](https://www.crowdsupply.com/krakenrf/krakensdr/updates/kraken-campaign-succe...) Firstly, we’d like to wish all our backers and followers a happy holiday season! In this update we’ll describe some progress we’re making on the code base, and some updates about manufacturing. Core KrakenSDR Code We have now released a beta version of the Direction Finding Code which can be tested right now by owners of our previous hardware version, the KerberosSDR. To make installation easy, a SD card image is provided for the Pi 4. Relevant instructions can be found on the latest ‘clientside-graphs’ branch of the krakensdr_doa GitHub Readme at https://github.com/krakenrf/krakensdr_doa/tree/clientside_graphs. As this is a beta image, there is no automatic WiFi hotspot connection, so you’ll need to follow the instructions to connect to your WiFi network first, and to run the script. If you have any suggestions, bug reports or questions, please use the [Github issues](https://github.com/krakenrf/krakensdr_doa/issues) feature. For those interested, the latest code updates optimize CPU usage and improve the update rates through various code optimizations, and use of the ‘numba’ numpy Python JIT compiler. For beta testers, we also now recommend installing your Python environment via Conda, which allows easy installation of the latest and fastest Python 3 versions, and easy management of the dependencies. If that all sounds complicated, don’t worry, as once the code is officially released, all the end user will need to do is burn the SD card, boot up the Pi, and connect to the web GUI on a browser. In terms of features, the new code adds fast spectrum graph updates, which makes checking on the spectrum and tuning much easier. Intermittent signal handling has also been improved. (For the nitty gritty technical followers, we have moved squelching from a time-domain based squelch to frequency domain-squelch. Time resolution down to about 1 ms has been maintained via windowed FFTs with overlapping.) Right now the squelch feature will automatically lock and tune to the strongest active signal within the decimated bandwidth, and will prevent updates if there are no active signals. In the next few updates in early 2022 we will be looking to add channelization features, allowing users to set specific channels in the decimated bandwidth that can be monitored. This will allow multiple direction finding bearings to be output to the multi-platform mapping software that is being worked on now. We have also added an easier way to control parameters relating to the DAQ. Instead of needing to worry about complicated decimation factors, and buffer, CPI sizes, you can just enter the desired data integration time and the desired bandwidth. Advanced users can still access these parameters via the Advanced checkbox. Mapping Code Updates Our mapping software dev, Manuel, has been working hard on the multi-platform network capable mapping software which will allow multiple distributed fixed and mobile KrakenSDR direction finding stations to work together by uploading direction finding bearing data to a central server for data fusion. This code is being built in Flutter for multi-platform use, with the use of Mapbox for mapping, just like in the Android app. The first stage is replicating the capabilities of the existing mobile Android App which is now close to completion. We expect to see more development on this feature in early 2022, with a beta hopefully ready by the time we ship hardware to customers. As this code is multi-platform, we expect this code to eventually replace our Android only solution in time. Passive Radar We’ve also started work on the passive radar code. Currently we’ve replicated the features of the KerberosSDR passive radar code under the new KrakenSDR codebase. The new codebase allows us to achieve much higher passive radar "processing gain" (aka integration), which results in better resolution and weaker detections showing up stronger at the expense of some time resolution. In the previous KerberosSDR code, the amount of processing gain possible was tied to the RTL-SDR input buffer, which if set too large could cause sample loss and high CPU usage issues. We’ve also worked on optimizing the passive radar code, and introducing numba, resulting in much faster update rates on the Pi 4. The Pi 4 is still not capable of running passive radar code at the maximum update rate however, and for advanced users that require the maximum possible update rate, we will be looking at creating GPU accelerated code for alternative single board computer solutions such as NVIDIA Jetson, or for standard PCs with GPUs. A quick test of the passive code was completed recently and below is an range-Doppler graph showing some results. (The setup was the same as in the passive radar video on the main campaign page). Some interesting points are that you can see the multiple Doppler returns coming from a helicopter, due to the helicopter blades producing multiple Doppler signatures. Some individual roads can also quite easily be differentiated. In early 2022, we will release this code on the GitHub for beta testing. In 2022, our lead developer, who works on the advanced passive radar features, will be back and he will be working on implementing methods to direction find passive radar returns, and plot them on a map. Then, for example, in the above image we could then see exactly which roads on the map are causing the returns on the graph, allowing for easy traffic monitoring. Manufacturing Progress We finished the pre-production PCB design several weeks ago. We are building 20 prototypes so we have enough KrakenSDRs to send to alpha testers. As we mentioned in the past, all of the long-lead components have already been acquired, so that part of the supply chain that is holding up much of the electronics industry won’t impact us in the same way. However, we do have a few custom-built parts, and those are currently slowing things down, such as the SMA connector. In order to maximize automated assembly, we specified a connector which could be soldered in a reflow oven, rather than by hand. Since we required a longer barrel than what is commonly available, a custom part is currently being made for us. It should be delivered to our contract manufacturer immediately after the first of the new year. Once the SMA is available, the 20 pre-production KrakenSDR will be assembled. Immediately after we confirm the latest PCBA (printed circuit board assembly), we will produce another 1000 PCBA. As long as there are no hitches, we will follow up with an additional ~1000 KrakenSDR shortly thereafter. We purchased enough components to manufacture a bit over 2000 KrakenSDRs. During our testing of the KrakenSDR that was featured in the campaign, we found that the enclosure could become too hot to touch in hot (30 C+) ambient environments with no airflow. In this hot ambient environment, the enclosure reaches about 60 C, which is a reasonable in-spec temperature for the electronic components, but given that there is significant thermal mass in the enclosure, touching the enclosure could be painful. In order to reduce heat, a cooling fan is being integrated onto the top of the device. It will sit where the logo currently is, and blow air through the fins. The fan will then be covered with a protective perforated logo plate. We’ve already conducted preliminary tests with a fan and have seen very positive results. We are now validating a specific fan and are modifying the enclosure design to accommodate it. Happy Holidays! We will be taking a break from updates over the holiday season, but will be back in January 2022 with fresh updates! Wishing everyone happy holidays!