UICL Concept

Here’s some news articles for the Underwater Imaging and Communication with Lasers (UICL) program I’m working on.

TC Palm

Newswise

I put the DRONE out in a small lake we have on campus and drove it around a bit with a joystick to test out how well the platform works.  Here’s some video of the test.

[See post to watch Flash video]

[See post to watch Flash video] ]]> http://www.brianramos.com/?feed=rss2&p=240 http://www.brianramos.com/?p=224 http://www.brianramos.com/?p=224#comments Wed, 18 Feb 2009 22:20:40 +0000 bramos http://www.brianramos.com/?p=224 I started working with the DRONE controller software again.  Here’s a picture of the DRONE,

DRONE Vehicle

Had a bit of an issue determining the IP address of the controller but no worries, Wireshark to the rescue!  I set Wireshark to probe the network looking for DHCP packets and read the IP address out of the DHCP offer.  I’ve been meaning to port my poor mans Zeroconf from Python to C so maybe I’ll take another look at doing that tonight.  Makes having to deal with determining IP addresses much easier and less of a hassle than setting up a real Zeroconf server.

Had another issue with calls to the SPI API causing segmentation faults.  Turns out it was a bug in the kernel on the controller so I updated to a new kernel from the vendor and it’s working fine now.  Tomorrow I plan on throwing this guy in the test tank and running it around a bit.  I might post some video if everything goes well.

I haven’t posted much after Monday because I wanted to avoid posts consisting of only four letter words.  It was a bad week.  I’ll be posting a summary of the week later on today.

Update: 11:00 PM

I started Tuesday with the realization that I made a big mistake on the mainboard.  My receiver’s connector had its odd and even pin rows swapped.  I could swear I’d checked that but apparently not well enough.  Now if the receiver cards were lined up on the bottom of the board they would be correct, so I hastily decided to unsolder the connectors to reverse them.  Until I realized that that won’t work because the LO connectors would now be offset in the wrong direction.  However by this time, some of the traces were damaged in the unsoldering process because all the copper in the board quickly sucks away heat, solidifying unexpectedly.  Now I didn’t trust the board.  So rather than try and patch up that board and worry about any unseen damages, I decided to populate a new board to start with a clean slate.

With my new board and the connectors on the original side, I set about making some connectors that will dispace the pins 0.1 inchs.  Luckly, I don’t really need both rows of pins as the even row is all ground connections and the LO connectors will provide sufficent ground for those low frequency signals.  I was able to canbalize long pins from some scrap connectors and bend them to get a working connector though it was tedious work.

Now with working receiver cards, the next task was getting the ADC’s working.  They were outputing all zeros but the problem was easy to fix.  One of the pins on the new board’s ADC wasn’t quite soldered down well so I reflowed all the pins and I started to get data.  Except that it was all wrong.  But it looked familiar, as if the bipolar pin was set low to unipolar mode.  Which it was.  Worse yet, it’s a leadless package so I’m going to have to unsolder the part to cut the trace underneath and then wire it to 3.3V with a very small jumper.

For the record, here’s a list of known problems with the current version of the mainboard:

• The JTAG RESET signal is wired to the wrong pin.
• The transmitter 870MHz LO connector is offset in the wrong direction.
• The receiver’s connector has its even and odd rows swapped.
• The ADC’s bipolar/unipolar pin is wired to low instead of high.

It isn’t all problems though.

The MAX232 is very quiet with the new input power noise filter.  The MAX232’s charge pumps were blasting out noise on the power line in a previous design and I had to enable/disable the drivers on every transmission.  Now they’re not even detectable.  I’ll be doing all MAX232’s with that filter from now on.

The 3.3V analog power line overall is very quiet; less than 5mV of noise on the scope which is pretty much its noise floor anyway.  I took a preliminary look at it with the spectrum analyzer and didn’t see anything above -55dBm which was the nearby FM station at 94.7MHz.  A shield room would be nice :-).  The voltage regulators do get very hot though as the board pulls around 900mA without the transmitter.  I need to add a heat sink across them.  Something like this perhaps.

The 90MHz LO works just fine.  It’s a simple oscillator with a 4-way clock splitter and terminating resistors so there’s not much that can go wrong but you never know.  On another design, I might add a PI-pad to reduce the signal level down a bit because it’s pretty booming (~8dBm) but not causing any problems.  I might also add a simple bandpass filter in there to attenuate the harmonics.

The DAC works great and will allow us to switch gains very fast.  And it supports simultaneous updating of all four channels which is nice.

I did some preliminary phase noise measurements of the 870MHz LO and they look ok.

The Receiver's 870MHz LO Phase Noise

The Transmitter's 870MHz LO Phase Noise

-81.5dBc/Hz at 10kHz offset is not bad considering my channel selectivity is 50kHz.  I expect it to improve once the transmitter is handling the modulation and I can set the PDF for 500kHz.  It should be around -90dBc/Hz so I’ll raise the PFD on Monday to see if it comes down.

870MHz Local Oscillator

A nice 870MHz signal.

Update 10:00 PM:

The synthesizer probably failed because it was heated to long during the soldering process.  Most likely it wasn’t the soldering of the synthesizer itself that did it but my need to solder another leadless package on the bottom of the board with my experimental dual sided hotplate method.  Needless to say, I’ve abandoned that method.

Replacing these leadless packages can be tricky but it’s not to bad if you have the right tools.

Lead Frame Chip Scale Package

First I preheated the board with a mounted hot air gun to around 250° F and removed the old synthesizer with a hot air soldering iron.  Then I cleaned and pre-tinned the work area leaving me with this footprint.

Leadless Footprint

Next, I placed the part down on the board to warm up and placed it onto its footprint after a minute or so.  Then I took my hot air soldering iron and swirled it around the part until I felt the solder underneath the part melt.

Placing the Leadless Package Down

Using a dab of solder on a fine tipped iron, I went around the part touching each pad.  Sometimes the pads might bridge but that’s usually not a problem because the flux in the clean up step with fix that.

Solder the Pads with a Fine Tip Iron

Finally with my low solids flux pen, I go around touching each pad with the iron.  This will cause the solder to draw up onto the package and usually break solder bridges.  A little clean up with alcohol and were done.

Cleanup with Low Residue Flux and Alcohol

I went ahead and cleaned up a bit more after the last photo but you get the idea.  You’ll notice that the alcohol and brush tend to break up the silkscreening a bit but that can’t be helped.

I noticed that the evaluation board needs the command sent to it twice to set the frequency which is odd.  At first I thought it was me hitting Load and then OK but it won’t take without Load/OK, Load/Load, or OK/OK.  I checked from power on to RF out with the logic analyzer to see if there is any reason why it would need to be commanded twice but found nothing.  For the hell of it, I commanded it twice (and more) on my board to no avail.

I’ve used the sister part before, the ADF4360-0, and had no trouble with it at all, proving that not all siblings have the same temperament.

Update: 7:33 PM

I’ve got a support request into Analog Devices so I’m waiting to hear back from them.  What I’ve found is that there is no output from MUX pin when set to “N Divider Output” and there should be a 500 kHz pulse train which explains why the loop filter is at 3.3V.  The N Divider and R Counter are fed into a phase comparator and its output passes through the loop filter to tune in the frequency.  So with no N Divider signal, it’s pulled all the way up as it tries to tune.

So far, what I’ve checked is:

• There are no shorts between any pins, power, or ground.
• Power and ground present where they should be.
• CE enable line is HIGH.
• 10 MHz reference input is present at pin.
• Serial data was checked with a logic analyzer against an ADF-4360-xEBZ1 Rev. D4 evaluation board and all serial and enable signals are identical from power up to output. My serial clock is 1.4MHz; slowing it did not help.
• MUX set to “Serial Data Out” properly parrots back serial data in, delayed by 24 bits.
• Mux set to “Open Drain Lock Detect” goes HIGH for approx. 100us then low upon setting the latches.
• Output stages are pulled up to Vvco with 47nH inductor.
• Voltage at Rset pin is 0.52V with 4.7k resistor.
• Time between setting Control Latch and N Latch is greater than 10ms.

The output is connected directly to a spectrum analyzer and there are no signals from DC to 2GHz. My latches for testing are configured as follows:

• R Latch: 0×300051
• Control Latch: 0×4FF180
• N Latch: 0×006C32

R Latch is set first, Control Latch second, and N Latch last.

Update: 7:39 PM

Implemented the code that sets up the synthesizer via SPI but the synthesizer doesn’t seem to work.  I’ve captured the SPI data from the evaluation board with Analog Devices’s software and on my board with the logic analyzer and they look the same so I don’t think my signalling is incorrect.

Synthesizer Evaluation Board SPI

Synthesizer Mainboard SPI

The only difference is my SPI is faster but well within the specification for the part.  It could be that the part is damaged or there is a short below the part from it’s exposed paddle to a pin.  Tomorrow I’ll go around the part and see if we have the correct values at each pin or shorts to ground.

NOTE: The markers in the images are all placed on signal edges.  There is a graphical bug that makes them appear off the edge when not zoomed close in.

I’m having a bit of a problem programming it. It programmed just fine the first few times I tried but now it work take at all. The CPU is running because I can see its serial output and the toggling of pins but the JTAG continually fails with a “Could not stop ARM device!” error. The only lead I have to fixing the problem is that the demo board I’ve been prototyping on has a older revision of the ARM and my current version of RealView MDK doesn’t have the new revision in the device menu. However, I wonder why it would have taken the programming at all if that’s the case.

I’ve tried the FLASH erase procedure but it still won’t communicate. I’ve checked continuity from all the JTAG signal lines to the ARM and they’re OK. I’ve also checked the JTAG signaling with the logic analyzer and the ARM seems to be responding. I can see where in the process the signaling deviates from the demo board but because the protocol is so obtuse, I don’t know why it’s failing.

Update: 6:07 PM

Here is a capture of the JTAG signals and where the demo board and my board deviate:

JTAG Working on Demo Board

JTAG Not Working on Mainboard

The JTAG signals deviate from marker A forward.  After that point, the JTAG looks like it’s trying over and over again to get the response it’s expecting as those black areas on the bottom image are a repeating pattern of 18 bytes.

I requested a quote from Keil for a renewal of our software maintainace agreement and it’ll run about $1469.  I’ll look a little further tomorrow but it’s looking like it may that I’m trying to program it as an older revision of the processor.

This is an 3.9nH inductor in an 0402 package making to 20×40 thousands of an inch or a little larger than a grain of sand.