In order to not hit something, you generally need to know where that thing is. On land, the meager human eyesight tends to be sufficient. On the water, however, the prospects are more dangerous and complicated. So, technology is required to ensure safe ocean voyages in the form of the AIS transponder system. The off the shelf solutions tend to work quite well, but [peterantypas] was displeased with the commercial offerings, and built what appears to be the first open source AIS transponder called MAIANA.

Automatic Identification System (AIS) is a GPS tracking system designed for maritime applications. Broadly speaking, it broadcasts GPS and other data at intervals over VHF radio. AIS is what allows the precise tracking of vessels by authorities, and online hobbyists. AIS is also often received by other vessels to augment radar improving boat to boat collision safety.

Most commercial AIS transponders used by sailors are rather bulky, expensive, come with a large power budget. The MAIANA project avoids these pitfalls by being entirely self-contained. The RF portion is largely made up of a STM32L4 micro controller, a SI Labs Si4460 ISM RF chip, and a Quectel L76L-M33 with a Johansson ceramic chip antenna for GPS. With such simple hardware, the PCB is easily small enough to fit inside the antenna assembly.

This design eliminates the need for long runs of multiple shielded RF cables to a bulky transponder unit inside. Instead, a simple Ethernet cable is used to transfer data to and from the mast. Inside the boat, a USB decoder is used to pass the AIS data on to a PC. This whole setup is remarkably simple and reliable, with hundreds of units having been produced since the project’s start.

While this is the first full blown AIS transponder we have covered, we have seen other projects utilizing the protocol. We have also seen quite a number of projects with the aircraft equivalent, ADS-B.

Thanks [Bernerd] for the tip!

WHOOP does not have the presence in the wearable space as other brands, but in certain circles, it’s a household name. Their business model requires you to have a yearly app subscription to use their fitness tracker, but here at Hackaday, we are big fans of actually owning the devices you buy — which is why we were happy to hear about an open source and subscription free WHOOP compatible app!

The goal of the so-called OpenStrap project is not to re-create the WHOOP app. Rather, the algorithms and processing methods are developed from scratch, based on public research. It’s all calculated locally on a 1 Hz interval, based on the data the WHOOP 4.0 device feeds the app. As such, the health data collected from the watch, never leaves the phone. While not the main goal of the project, the privacy improvement of the app’s serverless nature cannot be overstated. However, to display metrics, you first need to get data off the WHOOP to begin with.

The crux of the issue with making the WHOOP 4.0 work without the official app is the reliance on proprietary Bluetooth protocols. Fortunately, the protocol itself ended up being relatively simple. The WHOOP 4.0 amounts to little more than a series of sensors that sit on the user’s wrist. As such, the app can subscribe to the Bluetooth feed and decode the data, right? Well, the devil is always in the details with such things, and the protocol came with its fair share of quirks. The hardware clock needs to be synchronized, or it simply defaults to zero Unix time. Moreover, the analog sensors like, ambient temperature are given in relative ADC values, and are not terribly useful without calibration. Regardless, the result of the reverse engineering effort speaks for itself with the OpenStrap app able to recreate much of the functionality in WHOOP’s official app.

Quite often, devices reliant on proprietary apps are little more than manufactured e-waste. While we don’t expect many of you to actually own a WHOOP 4.0, we do hope to see the OpenStrap project keep at least a few out of the landfill in the future.

The Intel 80386 is a rather fascinating slice of computer history. It marked the first 32 bit X86 processor, and was a staple of early desktop computing. Like all chips, it has a number of quirks, one of which being the fact that all commands are executed in microcode. By this nature, it was a rather excellent prospect to be re-implemented in an FPGA core called the z386. However, it was lacking a feature native to the original 386, early start memory access. So to bring some performance to the z386 project, [nand2mario] went forth to fully implement this feature for FPGA 80386s.  

Instead of taking a cycle to find and allocate the memory required for executing the next instruction, the 386 would start this in the previous cycle. This is achieved in hardware by nature of having a separate memory management unit. In the FPGA, the key difficulty proved to be in getting the computation fast enough to execute within a single cycle. This change netted an approximate 9% performance benefit. However, for [nand2mario] this was too small a performance uplift. 

Some rewrites of the store cue allowed for cutting a cycle out of the process further improving the performance. However, more performance required slight deviations from the design of the original 386. Because code-branches are performance critical, the z386 project now computes the branch memory jump several cycles earlier than the 386, reducing the cycle time for the jumps from 9.25 to a mere 6. Some final changes to the microcode decode frontend rounded out the optimizations covered in this latest blog post.

The net result is an approximate 39% increase in performance in the all important DOOM benchmark. The z386 still not a complete project, the performance is still lacking compared to the 386, and it remains unable to boot Windows. X86 is complicated, which will take time, so make sure to stay tuned for more coverage! While you wait, make sure to check out our original writeup of the z386 project. 

Pauli Rautakorpi, CC BY 3.0.