This is a follow-up on the previous post. The central theme this time is “noise”.
After posting the last post in various places SA2KNG suggested “8bit float” on IRC, to which I immediately replied “µ-law”. µ-law and A-law are companding techniques defined in G.711 and primarily used in telephony. A-law is especially close to a binary floating point representation, including a subnormal range, but with no way to represent +/-infinity or NaN (not-a-number). Only 4 bits for mantissa is a bit restrictive however. A similar idea is to use 16-bit half-precision floats. This would give the same kind of compression ratio as the codec in the previous post, but with much simpler logic. The cost of this is some loss of precision. This isn’t a huge deal however, since our input noise is high enough to mask this effect.
The dominating form of electrical noise in our system is the Johnson-Nyquist noise from the 100 MΩ feedback resistors in our transimpedance amplifiers, which at room temperature contribute 1.3 µV/√Hz. Our analog-to-digital converter (ADS131A04) is configured with OSR=512 and gain=16, so the noise seen after the ADS131’s internal amplifier is √((1.3*16*√1800)² + 77²) = 886 µVrms (the 77 µVrms figure comes from the datasheet). With Vref=2.442 V this corresponds to an effective number of bits (ENOB) of 10.9. Hence an “seee mmmm mmmm mmmm” type of floating point representation should work well. It also leaves enough dynamic range for measuring very weak signals. The best of both worlds (:
I find it quite good to write these kinds of posts since it allows me to sanity-check my reasoning around things. Noise is an especially tricky subject with lots of traps. In writing this I discovered one error in my notes where I had not accounted for the J-N noise being amplified by the ADS131’s internal PGA. This helped explain the noise levels seen in some measurements.
No posts in a while, time for a technical writeup!
I (Tomas) did a small experiment around compressing 24-bit sample data today, in an effort to try to get more throughput out of the 115200 baud RS-485 connection we’ll have in our lunar electrostatic instrument.
Our hardware currently delivers three channels of 24-bit data sampled at around 1800 samples/s. With an overhead equivalent to about one channel’s worth of data this comes to 1800 * 4 * 24 = 172800 bit/s, more than our poor RS-485 bus can handle. The final version of our instrument will have as many as nine channels active simultaneously, which means spending 4-5x more time downloading than actually capturing data!
Since we want to get as much science out of our instrument as possible, I spent some time trying to investigate ways to increase throughput. Simplicity is key since we’re running on a 7.37 MHz 8-bit microcontroller.
The idea for a codec for this is based on two observations:
The combination of these two means that each sample can be “trimmed”, lopping off both most-significant and least-significant bits in a lossless process. An experiment with a 1027 B block of actual instrument data (7 B header + 1020 B data) yielded these results:
|lz4 v2||1018||data transposed prior to compression (least significant bytes first)|
|this codec||762||fuzzed with american fuzzy lop (afl)|
With the codec the samples compress to 16 bits each (from 24), which with overhead should result in a throughput increase of 34%. Not super great, but potentially useful. afl was quite useful for discovering bugs in the implementation. The other options performed worse (especially bzip2), and will most definitely not be worth the cycles.
TL;DR: a simple lossless codec can often work much better than a general-purpose compressor :]
RE: the project overall, we’re very busy getting our current prototype ready to send to IRF Kiruna. Hence the lack of updates lately.
See you next time!
Last week Tomas and Maria visited IRF, the Swedish Institute of Space Physics, in Kiruna. The reasons were two-fold: first the science part, which is mainly Maria’s area. The second reason was engineering, which is Tomas’ domain and the main focus of this post.
For the science bit, getting feedback from the space science community is important. It allows us to be reasonably confident that we know what problems expect when it comes to measuring. It also helps advertise our work to scientists that may be interested in our data, and gives ideas about possible future missions.
As for engineering, lots and lots of useful tips. In no particular order:
Cabling: wires should be bundled into harnesses. Pin headers + sockets are preferable, since they still allow some springiness but will not have much trouble with vibration. PTFE, Kapton and FEP are good, thermal vacuum compatible insulation materials. PVC is unacceptable. Flat flex is OK, but may crack or disconnect due to vibration.
Connectors: Every connector should be unique, so there is zero risk of incorrect hookup. Keep “protruding” connector elements for power on the instrument side, so that cables used for power have their elements “sunk in”. Typically this means female (sleeve) type of connector, but some pin types are also sunken. Use gold plated connectors.
Solder joins: Rosin core 63/37 SnPb solder has a predictable melting point and cleans well enough with isopropyl alcohol. Use clear Kynar heat shrink tubing where possible, especially on D-subminiature connectors, see picture below. This prevents loose pieces of wire from accidentally shorting pins
Cleaning: brush using pure isopropyl alcohol or 70/30 isopropyl alcohol/distilled water. The latter may be needed to remove certain salts. Rinse with pure isopropyl alcohol afterwards. DO NOT use ultrasonic cleaning if using any ceramic parts; they may crack.
Glue/epoxy: Scotch-Weld 2216 is thermal vacuum safe. Mix, then use vacuum to draw out any air trapped inside. After vacuuming, the mix is good for about 15 minutes. Use Scotch-Weld to hold down large ICs, spot glue bodge cables or anything else that might move but shouldn’t. Useful for gluing nuts, since locking nuts are not thermal vacuum safe.
PCB laminates: FR4 outgasses slightly, but is perfectly fine thermal vacuum-wise. High-voltage boards should use ceramic substrates such as Rogers R4003 since the outgassing of FR4 may create a rarefied atmosphere, causing arcing and equipment failure. This is not a problem for us luckily 🙂
Digital logic: short missions near Earth (such as ours) do not need any kind if special ICs. Mechanical structures that withstand vibration testing are thick enough to shield ICs from any problematic radiation. As an example, IRF have sent instruments using off-the-shelf ARM chips without problems.
Latch-up protection: a series resistor followed by a capacitor to ground is enough to protect chips from blowing up in case of latch-up. Power cycle to remove any latch-up situations.
Plastic parts: PEEK works well enough for most plastic parts, and is thermal vacuum safe.
Tape: usually Kapton is fine, but pay attention to the glue used. There are also tapes with specific thermal radiation properties which may be used in lieu of plating or painting.
These tips should be handy both for AMSAT folks and possibly anyone who’s looking into building vacuum equipment. Finally, I’m going to round this post off with some more pictures:
Thanks for reading! As always, you can be notified of new posts via RSS.
Don’t forget to follow our Youtube channel!
2017 is upon us, and we’ve kept busy as usual. One of the main goals for this year has been to get a working prototype as close as possible to “the real deal”. This means being able to amplify, digitize, demodulate and transmit data over serial to a host computer. I’m happy to say we’ve managed to accomplish this, after a dash in the days between winter solstice and new year’s celebrations.
The quickly cut together video below shows how we’ve gone from a fieldmill assembly on its own, to a partially assembled cube, to the fully assembled cube in our test box. Some final screenshots demonstrate data being analyzed in LabView and GNU Octave.
The focus moving forward is making sure we only use materials which are high-vacuum compatible, to be able to do thermal tests on the design we’re currently working on. There’s also more work to be done on the simulation front, and various bits of code need to be written.Parts for a piece of calibration gear has been ordered as well, which is needed to verify that the entire analog frontend works as expected. In short, 2017 is going to be a busy year!
It’s been a while since the last update, because a lot of stuff has been happening.
On the code side, IQ demodulation is done. This has been a major task for a while, with some troubles achieving phase correctness and correct buffer handling. The working code proves that 7 MHz is enough to do demodulation for our needs. There is still some room for improvement, such as using Timer1/Timer3 input capture to get more accurate measurement of tachometer/sample times. Some optimization could also be done, if we need to increase the sampling rate (unlikely at this stage). Current CPU usage is around 60%.
We also got some new motors with built-in controllers. This reduces our work load considerably. They also have much better regulation than our previous controllers, meaning faster starting and more stable rotor speed. The electrical noise is also considerably lower and the motors run quieter.
Circuit boards for our most recent analog front end design have also arrived, and all components except the operational amplifiers we need! This may have something to do with the holiday pressure on the postal system. Hopefully they arrive before New Year’s Eve. We should also have some new toys from Atmel in the mail. More on those in a future post!
Finally, some pictures: