As mentioned in a previous Post about my Receiver design, I have ordered a large amount of components to assemble a lot more units. Assembling this many boards takes a lot of time. If you don't organize your workplace and every process that it's going to need to build the device prior to the assembly it will almost certainly take a lot longer. I always sort and position most of the tools and parts used during assembly with about an arm length on my desk. There is nothing is more inconvenient and annoying than having to search for stuff while dealing with fragile electronics.
There are some more changes since the last post. First of all the receivers enclosure has changed to a 3d printed one as the old one was too fragile during the extensive testing that I have done. Also the overall volume has been reduced to shorten printing times and make it more useful in small airplanes.
There are some more changes since the last post. First of all the receivers enclosure has changed to a 3d printed one as the old one was too fragile during the extensive testing that I have done. Also the overall volume has been reduced to shorten printing times and make it more useful in small airplanes.
The next change was more an addition. The antennas are now secured with some special electronic grade silicone. This prevents the antennas from being ripped of the connector or PCB. I got the silicone from Aliexpress for about 2Euro, so no large investment for a lot more security.
And finally I changed the pinout of the auxiliary Telemetry Port to match FrSky without having to build a special cable. This was as easy as routing the pins to the matching locations on the second revision of my PCB-Layout.
This project has already been one of the most time consuming things that I have ever done in my rare spare time and that is also why it takes so long to do updates or even get new features made. However I did a lot of software work to get the vario finally running the way it should. The most time went into a bug in the Processor itself. The barometric sensor had every now and then jumping values in the order of a couple kilometers. After many tests I decided to look at the data on the I2C lanes... Sometimes the processor decides to transfer an extra byte or even a zero byte. After quite some time someone pointed me to the errata sheet from ST, where this bug was already listed with a possible workaround. The workaround is to use I2C only with DMA except for single byte transfers... For me, who has never really used DMA before, there was a steep learning curve. But after stepping into many common pitfalls and general misunderstandings I got it working. Now the sensor was responding as expected.
Another really wanted feature was a automatic gain control of the amplifier stage. The problem without these few lines of code where missing packets and even complete signal losses on short distances (about 2-3m) due to overloads in the receivers input stage. Disabling the receivers amplifier during bind and high signal periods in combination with some window comparison did the trick. Now the antennas can almost touch each other without overloading.
A huge software project for the future will be adding D16 LBT and a custom bootloader to update the firmware via the transmitter and therefore building a custom .frk file converting script. At the time I'm writing this, the first part of the d16 development is almost done. I'm already able to bind and receive channel values. I now need to look into failsave values, telemetry and lbt functionality. Last mentioned has to my knowledge not been reverse engineered entirely so some nice stuff to investigate and learn. So far the D16 protocol implementation has been a nice journey, because midelic and jry on RCGroups.com have done most of the hard work and I only have to implement it into my existing software.
