Jack Crossfire's blog View Details
Archive for November, 2012 - Page 2
Posted by Jack Crossfire | Nov 10, 2012 @ 03:03 AM | 4,680 Views
After 3 solid days, getting the 900Mhz chip radio to work with ARM was about as hard as getting it to work with PIC was, in 2009. It's the same chip, just a much higher clockspeed & a new driver.

Years of experience revealed the best way to drive the chips is not to use the hardware FIFO over SPI but to bit bang the SPI & connect the raw modulation pin to both UART pins. The UART on every microcontroller can be switched between tx only & rx only, allowing the pins to be ganged onto the single modulation pin.

This greatly shrinks the layout & allows the full 115200 baud with a very slow microcontroller. The great challenge was switching the radio between transmit & receive, so it would send telemetry. It needs a 5ms delay for the transition to finish, not a very easy time to measure on an 8 bit micro where all the timers are used up. So far, it's just using a hard coded counter.

It has to use a software start code & send the packet size just like the hardware FIFO. There's no other way to filter out the noise. Once the transition is finished, the latency in a 1 way stream is 1/115200 seconds. The voltage on 1 is the voltage on the other, delayed by a lowpass filter.

Over the years, the ability to detect a 1/115200 second time difference with a simple chip radio has led to the idea of measuring distance with low cost components. A pair of radios operating on different frequencies & hard wired so 1 directly transmitted the voltage...Continue Reading
Posted by Jack Crossfire | Nov 08, 2012 @ 03:36 AM | 4,329 Views
Takes lots & lots of prototypes. Marcy 1 is still getting redesigned, after 3 years. This time, increased knowledge about the radio chip which has been in use for 3 years allowed a much simpler design & a prospect for better reception. The need for custom boards isn't completely gone, since they have to fly in tiny aircraft & the camera requirements are very specific. 2 more board will have to be made. That's a lot of work.
Posted by Jack Crossfire | Nov 06, 2012 @ 01:12 AM | 4,483 Views
They would make a good wifi repeater or a dedicated router for outdoor internet access, but so far the laptop has just enough range & this rainy season is a real bad one for outdoor use. The laptop has a much better antenna than the USB dongles, making it a very good router. Things have gotten a lot cheaper since the days of requiring a $300 Gumstix just to get 600Mhz, or the original $200 PC104 boards that only did 233Mhz.

They work with the same RTL8192CU chips used on all the aircraft. They go at 1Ghz, which may actually not be able to process as much video in C as the quad core tablet in unabstracted, highly flattened, minimally indirected Java. The goal is to do all the autopilot functions on it, with the wifi merely sending visuals to the user.

Like all single board computers, the great problem is high speed I/O. There's no way to connect a board camera to a DMA port. Video is still constrained by the throughput of the STM32F407. At least it has USB for some high speed I/O.

Bringing the USB device mode up on the STM32F407 was a lot easier than the host mode. Interfacing a home made protocol with fixed packets sizes instead of a black box networking chip spitting out random packet sizes made it easier.

Now video comes into the autopilot computer without glitches. Not sure the delay is any different. Wifi was always nearly spot on, except for the occasional 1 second dropouts. It still requires compression, the mane limitation. For high speed video on the rasberry, you're looking at a hardware codec.

Moving into a commercial period of UAV development means doing a lot more with off the shelf eval boards instead of home made boards for the lowest bidder. The output can no longer be something that can be reused later as a home made, minimum cost UAV.

There won't be another home made wifi camera board like Marcy 2. Already, the task would be easier by just connecting a rasberry pi to a webcam. Attaching the Marcy 2 board to it with USB is almost just a nostalgic move.
Posted by Jack Crossfire | Nov 01, 2012 @ 03:10 PM | 4,338 Views
After 3 weeks & producing a fully functional app, decided to put Android on hold & focus on iOS development. The customer was just going to port all the Android work to iOS, with later plans to port it back to Android after it became a product, which seemed ridiculous. If it ever went to a product, it would inevitably be profitable enough just to leave it on iOS, since modern product lifetimes are so short.

So there was an offer to support iOS development. Major Marcy was a confirmed Apple fan. I didn't want unattainable love to determine direction, which gave Android some points, but so much Android software is barely useable, from the slow keyboard to the clunky browser, it really only had a future running my own software, which deliberately avoided all the Java conventions to run fast.

If you program like C, avoid indirection & nested functions, use hard coded constants, copy class members to local variables, Android can run a tight loop nearly as fast as C by just in time compiling it. But no matter how hard you try, the lack of unsigned variables & lack of typecasted pointers to memory are an insurmountable barrier to getting full use of the hardware.

Startup time for a program can also never equal C. Android apps take forever to start, even the dead simple autopilot.