Saturday, May 28, 2016

Satellite Tracking (Update)

In a previous post I discussed the possibility of tracking satellites through the use of 9 degrees of freedom (9DOF) sensors to indicate the position of an otherwise arbitrarily positioned antenna.

Interestingly enough a kind reader pointed out to me a recent publication of a nearly identical solution to what I had envisioned.  Not wanting to necessarily duplicate the work of someone else, I faced the dilemma of continuing my efforts without reference to this other body of work or not.  It would be nice if the other author had done a poor job and I could improve on his work by publishing an update with an improved implementation.  However, I would find it difficult to improve on the work that has already been published.

So, my solution is going to be to recommend that you go take a look at the fine work done by Elwood Downey over at http://www.clearskyinstitute.com/ham/AST/ and leverage the excellent write-up and complete code listings if you are interested in building such a device.

I will be taking my own advice and implementing Elwood's solution, no doubt customizing things along the way.  Once I have that functional, I will publish an article here on my implementation of his work.

Nice work Mr. Downey!

Wednesday, May 25, 2016

Wednesday, May 18, 2016

Windows 10

So after 26 years at Microsoft, you would think I would welcome Windows 10.  Not so much.  Especially given I came home last evening and opened up my laptop to find it in the middle of an auto-magic update to Windows 10.

That being said, thus far the experience has been fairly seamless.  Everything was still where I left it and with the exception of the touch pad having some quirkiness I have not found any issues with windows or my installed base of applications.

The other advice I have for you if you decide (or have it decided for you) to install Windows 10 is to actually read that bloody license agreement.  Once you recover from that experience, do not take the automatic settings offered to you and actually go in and turn off the options to kindly share all you browse history, all your contacts, all your usage patterns and "other data" with my old employer and unnamed third parties.  Turn off Cortana unless you actually wish to have a live microphone transmitting everything said in the room to another unnamed third party.

Ok, so enough ranting.  I am now in the Windows 10 camp, wiping the slime off from the process of how I got here and more than slightly disgusted with the business practices of my former employer.

Monday, May 2, 2016

And now for something completely different...

Spent the weekend out at the coast with a group of aviator friends at the only beach state airport in the lower 48, Copalis State Airport at Copalis Beach, WA.  The sand is rock hard at low tide and I think you could have landed a 747 out there.  The airport normally has about 220 aircraft operations per year.  We landed over 54 aircraft on Saturday from all over the Pacific Northwest, hung out for several hours and departed without leaving any trace of our having been there.  The weather was perfect with about 15 knots of wind straight out of the north making for a rather epic day at the beach.



Sunday, April 24, 2016

Satellite tracking

The beginnings of a new project.  Software is coming together, but now it's time to pull together the hardware.  This will be an antenna azimuth/elevation  satellite tracker.  In previous posts I have explored the calculations necessary and the details of using hobby servos to create a simple proof of concept.


For now I am experimenting with the ATMega2560 board (on the left) as it has plenty of flash and RAM space for the task at hand.  I plan to control the device via a web page that it serves up, so for now I have an ethernet shield attached, though in the end the plan is to use WiFi.

Calculating satellite passes requires an accurate position for the observer in terms of latitude and longitude, but also elevation and time-of-day.  I am using a GPS module to provide this information (lower right).

While the mighty ATMega2560 is certainly capable of generating the necessary PWM signals to position servos, I have decided to offload that to separate controller based on the PCA9685 which provides I2C interfacing of 16 channels of 12 bit PWM data.  This particular board was originally intended to be used as an RGB LED controller, but my plan is to re-purpose it for this task.  It has its own internal 25 MHz oscillator that offloads the ATMega2560 from having to generate these signals.  That, plus the fact that I happened to have one on hand drove the decision to use this component to drive my servos.

After spending some time in the Avionics industry and working on electronic aviation attitude indicators, the math involved in Euler angle solutions to the orientation of a rigid body, plus the mapping of raw gyro, accelerometer and magnetometer sensor data into 3D space is a bit tedious.  Fortunately for me, Bosch has done an amazing job of taking MEMS data from on-die sensors and adding an ARM Cortex M0 processor to produce a single chip solution that abstracts away all the raw sensor fusion and spits out data directly in quaternions, Euler angles or vectors.

The plan is to use this sensor mounted on the antenna fixture to measure azimuth and elevation relative to the calculated position on earth with no careful alignment of antenna orientation required.  The Arduino will accept keplerian elements for the desired satellite and then automagically track the spacecraft as it passes overhead.

More updates as this comes together into a demonstrable solution.

Saturday, April 16, 2016

Interesting problem

Today, I was writing some code that had some bitmap files embedded in them.  Not wanting  to waste space, I decided to use gzip to compress the bitmap.  After converting the compressed file to something that looks like a byte array in C, I get something like this:

unsigned char bitmap[] =
{
    0x1f, 0x8b, 0x08, 0x08, 0x2d, 0x87, 0xf9, 0x56,
    0x02, 0x0b, 0x69, 0x63, 0x6e, 0x5f, 0x73, 0x79,
    0x6e, 0x74, 0x68, 0x2e, 0x62, 0x6d, 0x70, 0x00,
    0xed, 0x99, 0x31, 0x0e, 0x82, 0x30, 0x14, 0x86,
    0x45, 0xa4, 0x5f, 0xf6, 0x0f, 0x21, 0x93, 0x3c,
    0x23, 0x70, 0xbf, 0xab, 0x06, 0xff, 0x9e, 0x00,

    .
    .
    .

    0x00, 0x00, 0x00, 0x00, 0x00, 0x42, 0xe1, 0x05,
    0x5e, 0xd7, 0xb8, 0x1c, 0x36, 0x40, 0x00, 0x00
};


So, nothing terribly interesting in that, but after compiling this into an executable, I get trapped by my virus scanner saying that my shiny new executable has a virus.  If I comment out the bitmap part of the code, no virus.

Apparently whatever byte pattern is created by compressing this particular bitmap gets flagged by my virus scanner, so in order to debug this code, I need to create an exception for the executable I am producing in the virus scanner.  Never had this happen before, but is certainly an artifact of the world we now live in.

I ran into another interesting trap while unit testing this code.  The basic problem at hand was to embed a series of bitmap files in executable code that could be reconstituted at will.  So, to unit test this code, I created the list of bitmap files and used gzip to compress them into a series of filename.bmp.gz compressed files.  Each of the bitmaps is 16k bytes and they compressed down to about 1k on average, so the savings is significant.

I created a utility that would take a list of file names and generate a C source code file similar to what is shown above which was then included in a unit test program.  The test program recreated the decompressed file using my decompression algorithm and wrote the resultant file back to the disk in a different folder.  What I expected was to see a directory full of identical files to the original set.  What I got instead was about 1/3 of the files had 2 or 4 bytes extra.  The rest were identical to the original.

This as you might guess had me more than a little concerned that my decompression algorithm, while not detecting any errors, including a CRC check of the decompressed memory image of the file, was still different on disk than the original by length and therefore content.

Loading the bitmaps up into an image viewer showed very minor corruption of the image.  Rats...

To check this out, I did a binary difference of all the affected files and I saw an interesting pattern emerge.  Every file that contained a 0x0A byte value in the original file, had a two byte sequence (0x0D, 0x0A) replacing it in the corrupt file.

For those that spend some time programming computers, this may be recognized as an automatic Unix/Linux end-of-line convention being replaced by a Windows end-of-line convention.  Unix/Linux uses (typically) line-feed characters only at the end of a line of text in a file whilst Windows (typically) uses a carriage-return/line-feed pair of characters.  (Thanks Microsoft...)

The cause of this result was failing to remember to open the new file in binary mode rather than non-binary mode which caused the file write operation to replace every line-feed character in the file with a carriage-return/line-feed pair.  A simple change to the file open to use binary mode and the resulting files were now identical to the originals.  Don't forget to unit test your code.

Saturday, March 19, 2016

Audio Glitches

How do you find something that takes four hours to occur, and then when it does it is over in 10 ms?  I find that it is really hard to be there when it happens.  When it does happen and you can capture the event, how do you figure out the root cause?

This reminds me a bit of the Pitch Drop Experiment, probably one of the longest running scientific experiments I have ever encountered.  Fortunately my problem is reproduce-able in hours, not decades.

The audio signal path is, to say the least, complicated.  Audio originated from a USB source got transmitted to a dedicated micro-controller.  From there it traversed an I2S bus to a DSP where some sample rate conversion is done.  The I2S bus then continues on to an Audinate network audio device where the audio is deposited on a Dante channel and sent via an Ethernet network switch onto a private LAN network.  On the other side of the network, the audio goes through another network switch into another Audinate device and then across an I16S bus to an FPGA where signal switching can be accomplished.  From there across an I32S bus to another DSP where any effects and other audio mixing can be done.  The composite signal then returns through the same path in reverse to the USB device that originated the signal where it is recorded.  What could possibly go wrong?

Well, surprisingly little actually does go wrong, but when it does it can be a bit subtle, so how to track it down?  Well, there are eight signal path segments in each direction.  My approach is to try and isolate each segment and verify them individually.  I needed to keep the audio signal in the digital realm as I certainly didn't want to introduce the complexity of digital to analogue conversions, plus the issue reproduces in the digital realm.

Since one piece of equipment in the scheme was from a 3rd party, the first task was to verify it could source and record digital audio without error and without using any of the suspect equipment.  So, I purchased a digital audio USB interface that would allow me to loop back said audio while keeping it in the digital realm.  I chose a commercially available USB to S/PDIF adapter and just looped the S/PDIF output back to the input.  Now the USB device could playback and record its own signal and see if an exact copy was produced.  No problems found.

So, in the interest of divide and conquer, I started by sending audio all the way to the FPGA but then intercepting the outbound signal and routing it to a 32 channel hard disk audio recorder.  This allowed recording of the digital signal at the mid-point of the signal path while simultaneously recording it at the return end of the signal path.  Multiple four hour runs were free of errors at the signal mid-point, but still had glitches at the return end of the signal path.  This eliminated all but one signal path in the outbound direction.  To eliminate the remaining signal path, I looped back the audio signal at the DSP at the far end of the path back to the FPGA before sending it to the digital audio recorder.  Still clean.

So, now with half the signal path eliminated, I generated a 997 Hz sinusoidal tone in the same DSP (997 is a prime number) that was used to loop back the signal above in order to isolate the return path.  I have audio glitch testing software than is used to analyze the 48,000 audio samples per second over four hours for abnormalities  This ends up being several gigabytes of data.  Once a reproduce-able error is found, I find that generating a triangle waveform where each sample starts at zero and rises by a value of one to the maximum value and the decreases by a value of one to the minimum.  My analysis software can find glitches (basically looking for vertical edges over some threshold) with either sinusoidal or this kind of ramp-up/ramp-down waveform.  When it comes to looking for firmware issues of dropped samples or buffering issues, I usually use a sawtooth waveform.  At the sample rate of 48 kHz, a ramp from zero to maximum and a sudden drop to zero of a 16 bit sample is about 1.365 seconds.  It just sounds like a ~1 hertz click.  At 24 bits, it is a much slower changing waveform at nearly 350 seconds.  Using this kind of data provides predictability to the expected data, making it easier to recognize when things are not working and is of sufficient duration to ensure that no waveform can repeat itself inside any digital data buffering scheme.  Additionally, specialized code can be written to examine the binary data flowing across the system at any point and predict what should be happening at any given time.

Removing complexities in the Ethernet segment such as removing external network switches and using direct connections between pieces of equipment in order to simplify the setup failed to resolve the issue.

The return audio path ended up being the source of the audio glitch.  By having the ability to record the audio at each end of the complete audio path, the next task was to move one signal segment at a time down the return path and loop it back to the recorder.  This allowed isolating each signal segment and being able to rely on previously tested paths to perform the recording.  Again, using divide and conquer techniques, I did a binary search of the remaining signal segments.  If I had 8 segments to check, I went halfway down and looped back to the recorder.  If a problem was found, divide that signal path in half and retest until the offending segment was found.

In the end some restructuring of DMA priorities on one of the micro-controllers and some DSP work was involved in resolving the issue.





Friday, December 25, 2015

More PID ramblings

First of all, Merry Christmas!

Since I cannot seem to turn my brain off on this topic I have been semi-immersed in for a number of weeks, I wanted to jot down a few thoughts on the topic of PID controllers.

My goals in using a PID controller with a mechanical fader that is driven by DC motor are simple, to wit:

  1. Instantaneous snapping to a new position once loaded into the controller.
  2. Positional accuracy and repeatability when the same position is loaded.
  3. Smooth movement of the fader control under PID control when set point changes are small and frequent.
  4. Tolerant of "stair-stepped" set point changes arriving at non-regular or varying intervals while still maintaining smooth movement.
So far, I have achieved the first two goals.  To date, I have been using a positional PID in an attempt to meet all these requirements.  A positional PID is one that takes a positional set point and a current position as input and produces the necessary output to drive the fader to its new position.  It takes care of acceleration and deceleration as necessary to arrive quickly at the new position.

However, when trying to achieve smooth movement that is quite slow, I find that a positional PID is insufficient for the task for the following reasons:
  1. A PID tuned to aggressively snap to a new position is a poor experience when trying to achieve slow but smooth changes to the position.  The fader tends to be very jerky and/or noisy.  The effect looks like a long-term crack user trying to be cool when the authorities arrive.  I have attempted to use multiple tuning settings where I reduce the gains of the P, I and D terms, but while it improves things, it is still unacceptable.
  2. I find that it takes approximately 30% of the motor speed range just to get the fader to move if it is already stopped.  Once it overcomes inertia and friction it will suddenly lunge forward and likely overshoot the desired set point if it is close at hand.
  3. Once the fader is in motion, it takes a lot less energy from the motor to keep it in motion, but there is still a fairly significant dead band in the motor speed range where the fader will stop again if the PID output drops too low.  Anytime the PID calculation must reverse direction in order to slow motion, it must necessarily pass through this dead band on both sides of zero.
What is needed for smooth motion out of a PID is to have the PID control the velocity of the motor, not just to move it to a new position.  I have attempted to simulate this using a positional PID by limiting the range of the output of the PID to something lower than the maximum speed of the motor when it is desired to be non-aggressive about positioning.  However, what I find to be true is that while it helps the overall effect, the results are not sufficiently predictable or repeatable from one fader to the next.  They all have their own friction profiles and while they are carefully manufactured, the motor movement transfer function from one fader to the next varies considerably.

So, to provide smooth movement for non-aggressive position changes, what is needed is a velocity PID that will control the speed of the motor according to a motion profile.  I will be implementing a trapezoidal motion profile where the motor will accelerate to a maximum speed, hold that speed and then decelerate to a stop at the desired position.

So, I think I need the following:
  1. ​Desired velocity - I will calculate desired velocity based off the current positional error.  When the desired position changes, we start moving in that direction according to a motion profile.
  2. Current velocity - I currently calculate this as the derivative term of positional PID.  The first derivative of position is velocity.
  3. A second PID to control motor velocity when being non-aggressive about positioning that will control motor speed according to a motion profile in a tight control loop.

We can visualize position, acceleration and motion profiles as follows:


To determine the desired velocity, I will calculate the positional PID error.  This is simply the difference between the current position and the desired position.  The further I have to go, the faster I will go up to a maximum limit.  As the fader moves, the error changes (approaches zero) as the fader approaches its target.  The fader loop will calculate the desired velocity as the current position changes towards the target.  As friction changes, voltage changes and other external disturbances affect the actual velocity, the PID will calculate the necessary correction in velocity to stay on the motion profile.

More to come...

Sunday, December 20, 2015

Christmas Math

Just for fun...



I wish you all the best in this holiday season.