SMALL - SMALL - Telemetry SMALL - Radio
Jack Crossfire's blog
Posted by Jack Crossfire | Nov 25, 2013 @ 11:10 PM | 2,371 Views
It actually has a way to directly connect a UART to the modulation. The problem is it can't do GFSK in that mode. It also needs a trigger to enter transmit mode. It would be quite involved. The preamble generation & detection would have to be done on the host. Some pins would have to be soldered.

Since the trigger would use the same old slow UART, it would need to buffer as much as the FIFO mode & make any latency advantage a wash. It would allow packets larger than 255 bytes, but that would be more susceptible to errors.

It's not hard wired to do 256 kbits/sec. The data rate can be set to 230400 bits/sec to better synchronize the transmit FIFO with the UART. Si recommends using a register calculator, but they don't provide any obvious register calculator in the wireless development suite. The existing register tables can be interpolated to give values that work for 230400.

The next big win was letting the beacon rate dynamically adapt to the size of the packets. That got the download speed up to 107520 bits/sec with no uploading & a download speed of 65280 bits/sec during a maximum upload speed of 59840 bits/sec. It couldn't be symmetric because it has a minimum beacon rate.

Having a master sending beacons to schedule the packets has remaned a lot faster than cooperatively trying to allocate time slices. The speed limitation may now be entirely the USB adapter, with a custom USB solution getting above 128 kbits/sec. It's still not fast enough for video, but it's almost bearable for static page loads.
Posted by Jack Crossfire | Nov 24, 2013 @ 08:45 PM | 2,366 Views
1 byte sequence numbers proved not enough to handle the error rate, so the headers were increased to 3 byte sequence numbers. They would just increase, leaving no question about whether a lower numbered packet was in the past or future. It would take 91 hours for them to wrap around.

That lowered the download speed to 96 kbits/sec. Then there was a case where it would lose the sync bytes & require a hack. After many more corner cases, the USB serial ports finally evolved into the biggest source of lockups. The FTDI board & not the PL2303 was the 1 which 1st died. The write call would freeze until it was unplugged.

If USB serial ports were the standard in the days of massive dialup call centers, they would have become a lot more reliable. That wasn't what happened & the 16550 was the chip which ended up hardened by the call centers of those days.

So the next step would be custom USB interfaces for the radios. It would buy slightly more speed. At this point, having experienced none of the expected range increase, barely usable bandwidth, & pretty lousy reliability, it makes more sense to get an ultra cheap access point from Walmart, extending the range with a waveguide.

96 kbits was still double what GSM or dialup could do. It's too bad you can't buy your own private LTE headend. 3D print anything you want except your own ISP.
Posted by Jack Crossfire | Nov 22, 2013 @ 04:52 AM | 2,541 Views
It was finally decided to go for the next big win, manely directly connecting the serial port to the modulation of the 3drradio instead of buffering complete packets in the 3drradio.

The Si1000 can't really connect the serial port to the modulation, but it can get real close by carefully synchronizing the FIFOs. It also automatically stops transmitting if the transmit FIFO runs dry. No 100mW radio chip is going to let you leave the transmitter on without transmitting data. The trick is running the air data rate 1 stop lower than the serial port data rate to keep the FIFO full.

Nothing is ever easy, in the wireless business. The ENPAC, CRC flags have to be set. Never could get it transmit directly from the FIFO without setting it to calculate a CRC & packetize it. The FIFO thresholds have to be perfect. The interrupts have to be managed. There have to be a lot of timeout handlers.

The USB adapters are not equal. The FTDI has to be the base & the PL2303 has to be the roamer. 1 of them isn't buffering properly.

So that was the serial port during a transmit & receive when the 3drradio had to buffer a complete packet before transmission, then buffer it again before reception. The 7ms delay was when the packet was in the air. That was without TDM. All the time during the serial port transfers was unused spectrum.

That was with the serial port directly connected to the modulation. It left only 1.5ms between transmit &...Continue Reading
Posted by Jack Crossfire | Nov 21, 2013 @ 04:22 AM | 2,677 Views
Did another round of testing with the IP over 3drrradio. The 3drradio is 1 of those radios, like the XBee, which shuts down if it detects a returning signal during its own transmission. So an attempt to use XBees for 1 direction with 3drradios for the other direction resulted in all the senders shutting down. Their tuning filters were not sharp enough to isolate 2.4Ghz from 900Mhz.

A bit more tweeking of the parameters got the download speed to 60 kbits/sec & the upload speed to 15 kbits/sec when everything is absolutely perfect. It's still too slow for the intended application.

The original idea of 4 cc1101 radios at 115200 bits/sec was the only thing with acceptable bandwidth, but the range was too short. But that experiment just directly tied PPP to the UART with no resends. Maybe the latest algorithm would work.

Simply tying the serial ports together at 230400 baud gave 173 kbits/sec in both directions, with the same resend algorithm. At 115200, it did 87 kbits/sec. The advantage is each direction has its own wire. The limitation is the latency of the serial port dongles.

The 3drradios & Xbees are limited by the need to buffer a complete packet before sending or receiving on the UART. If they could directly connect the UART to the modulation, they could pack in a lot more data.
Posted by Jack Crossfire | Nov 20, 2013 @ 03:24 PM | 2,207 Views

After months of secrecy, a photo revealing a 2nd X-47b appeared. That 2 were built was always widely known, but seeing 2 at the same time conveys a feeling that more must be around, or there must be a large budget.

There really are only 2 & the socialists really don't have enough money to build any more. The thought of compulsive health insurance, hyperinflation, & 20% social security tax spreading to the entire world makes you grateful that Americans can't afford to build any more.

The human brain may be wired to enslave itself, but the natural forces of economic scarcity have always prevented the path of enslavement taken by the USSR, China, & America from spreading, in the long term.
Posted by Jack Crossfire | Nov 20, 2013 @ 06:12 AM | 2,337 Views

Took another swing at the flashlight problem. The easiest way to make it more efficient was to boost the voltage to 9.9V & power 3 LEDs in series. 5 strings of 3 LEDs would suck 200mA. Bucking it down to 3.3V would take 600mA, a real challenge for a tiny inductor.

Made an exact, miniaturized copy of the microphone boost converter from 2 years ago & changed the target voltage to 9.8V. In the worst case of boosting 6V to 9.8V with 200mA, the MOSFET hit 60C & the diode hit 60C.

In reality, the lowest input voltage is 6.6V, at which point the battery is destroyed. The nominal voltage is 7.4V. The actual current for the 15 LEDs ended up being 170mA. 4 strings ended up using 30mA & 1 string ended up using 50mA.

Powering 15 LEDs with the boost converter now takes 400mA. Using the linear regulator, it took 600mA to power 10 LEDs. The battery should last 2 hours instead of 1. That's the power of the boost converter. You can always buy a more stable boost converter that does it in a lot less space, but that comes with a $15 tag.

...Continue Reading
Posted by Jack Crossfire | Nov 18, 2013 @ 07:11 PM | 2,370 Views

Looking at video of Battlefield 4, it's pretty impressive how much game graphics have improved, in the last 20 years. A frame by frame analysis of the compressed 1280x720 videos available reveals no difference between the PC & PS4 versions, as some kids have claimed.

The improvements have been slow & incremental, since the 1st Duke Nukem 3D game came out. The polygon count is getting to where the outcome is going to depend more on the quality of the artwork than any improvements in the game engine. It's not easy to make artwork that shows off the high polygon count while still looking like the real world. Motion capture has also contributed to better character animation.

The camera motion is a lot higher than it used to be. Games have gotten more nauseating because the camera moves around a lot more. 12 hours of Quake II were bearable, as it only moved in 2 dimensions. Battlefield 4 becomes unbearable after a few minutes, as the camera constantly rotates, shakes, & zooms. Where movement used to be continuous, it's gotten more jerky.

They've gotten rid of the extreme violence of Quake II. They don't show the enemy guts flying around, anymore. Views of the enemy getting shot are always kept very far away or off camera, with no blood. Even the knife slitting is kept off camera. Quake II must have been the peak of violence.

Female players have gone away. That peaked around 2001.

There are 2 dream games:

1: a...Continue Reading
Posted by Jack Crossfire | Nov 17, 2013 @ 10:39 PM | 2,492 Views
Internet over 3drradio (2 min 40 sec)

Some testing after all that development was pretty disappointing. The urban apartment complex range was 150ft. It was much farther than wifi, but so slow using it to load any web pages was barely survivable. It would be useful with the ancient email client Pine or a phone app, but the modern web based gmail was hopelessly slow.

The better option is still a waveguide antenna on a standard wifi router. The wifi standards have just been optimized to get the most TCP/IP performance out of the available power.
Posted by Jack Crossfire | Nov 17, 2013 @ 04:15 AM | 4,516 Views

Having only a 3drradio set as a 230400 bits/sec solution, it was worth hacking it to try to get the most bandwidth. Comment out most of tdm.c, most of packet.c, disable the broken script & you can get the fastest 2 way communication out of it. A bit more hacking & it did effective CRC rejection before sending on the serial port. The CRC encoding was still done on the host. It also properly framed the full duplex packets.

That got 53600 bits/sec download speed & 11200 bits/sec upload speed, 2x faster than the stock firmware. It could actually load some web pages, with enough patience.

The firmware CRC rejection got it another 300 bytes/sec on the upload speed. There isn't enough RAM to have the entire full duplex scheme in the firmware.

The 3drradio was definitely a study in how many thousands of lines of code you can make hello world take. There must have either been a simpler way to accomplish what it did or it was the product of years of evolutionary programming.

With all the excess code removed, the 3drrradio no longer locks up, either. It annoyingly would lock up after a certain amount of time at maximum full duplex usage. It would recover after opening a serial terminal & injecting some random data into the stream.

Would say even in its intended application as a telemetry radio, it could do better by saturating the bandwidth with repeats.
Posted by Jack Crossfire | Nov 15, 2013 @ 07:50 PM | 2,081 Views

is horribly impractical, but works with enough glue.

No idea what motivated this, but once you get obsessed with a communication problem, nothing can stop you. It might be the hope of getting very long range or the desire of unemployed programmers to remember they can still write programs.

Wifi isn't really wireless because the range is useless. The phone company is worthless because it stops the moment you stop paying. Everyone dreams of running PPP on their own private, long range serial port radio that can reach for miles.

A serial port radio like the XBee, 3DRRadio, or CC1101 promises real wireless range, but has issues.IP requires full duplex asynchronous communication. Hook up your PPP connection directly to a 3DRRadio & it won't go anywhere.

The best results from serial port radios have come from filling the entire bandwidth at the highest bitrate with repeated packets & hoping some data makes it through. The fastest full duplex has come from constantly broadcasting beacons & waiting for replies, regardless of data usage.

It's not an efficient algorithm & it doesn't reach the theoretical maximum bandwidth, but it's practical. The algorithm would ideally be on the radio module instead of the host computer, but having it on the host allows the radio modules to be interchanged.

The idea is to have a sliding window of packets constantly rebroadcasting until they all get ACKs....Continue Reading
Posted by Jack Crossfire | Nov 13, 2013 @ 05:45 PM | 2,158 Views
The job market dropped dead in November. Did the western world stop writing software?

It's time for another round of applying to colleges for another degree. Last year's attempt ended up nowhere. It was fairly easy to get in, in the 1990's, but now it's super competitive just to get a basket weaving degree.

This year, there will be more attempts. There seems to be a pattern of having to borrow $100,000 for more education, every 10 years. Everything you earn goes back to education. The only winners are the banks. The economy constantly changes, but workers are still faced with an obsolete system that requires formal education & assumes 1 degree for 1 job for life.

There are stories of people in this death spiral moving to Asia to leverage the lower cost of living against their student loans. It's a temporary situation. There are immigration laws. Their debt is still denominated in the higher cost of living. They still have to pay US taxes.

The large number of continuing education seekers have made things complicated. There are no longer federal loans above a certain number of credit hours & tuition is double. Most public schools no longer offer 2nd degrees.

The economically easiest solution is to return to Fl*rida & finish the EE degree started 15 years ago. It would be emotionally difficult. There would be at least 1 flight back to Calif*, but it wouldn't be the same as driving down the 5 to a place that was previously earshot away.

The emotionally easiest solution is to discard the EE courses & start a CS degree in Calif*. They're very competitive & unlikely to let me in. No EE program in Calif* would let me in.

Either way, in 18 months, Calif* becomes a very depressing place & the happy place becomes Washington DC. That's closer to Fl*rida.
Posted by Jack Crossfire | Nov 11, 2013 @ 04:30 AM | 2,295 Views
Wiedemann run 2 (7 min 42 sec)

Had the brushless gimbal for this 2nd run up the mountain. It was either the need to manage the gimbal or the intense mileage lately, but it was 10% slower than the April 27 video. Ran 53 miles in the 5 preceding days. In the 5 days before the April 27 video, ran 12 miles.
Posted by Jack Crossfire | Nov 10, 2013 @ 02:34 AM | 2,447 Views
Posted by Jack Crossfire | Nov 08, 2013 @ 08:41 PM | 3,648 Views

It finally had to be put down so its enclosure could be used to make a flashlight. The enclosure probably won't last long, anyway.

It was made during the rcgroups downtime in Feb 2011, before there was a phone which could do the job. It was a speedometer/distance tracker/odometer/stopwatch/GPS logger/GPS clock.

The LCD was driven with voltage dividers & ordinary logic pins from 0-3.3V. It took some doing to reverse engineer how a passive matrix LCD could be driven from logic pins. The result was very contrasty & more legible than the device the LCD originally came from, but if it got hot, all the segments went dark. If it was too cold, all the segments stayed clear.

The LCD flex cable was another failure point. Pressing it down enough to make good contact squeezed the liquid out of the display.

The 8 bit PIC spoke the current speed through headphones, using the PWM driver. It was made without the aid of an oscilloscope, which nowadays sounds incredible. Those headphones were lost in 2011 & never found again. The speedometer function was used to run fast, but it required holding the GPS module very steady.

The distance tracker didn't work as well as hoped, either. It glitched way off indoors & you had to remember to pause it to go indoors. Phones still have the same problem.

The stopwatch & clock just copied GPS, so the stopwatch was accurate to 1 second. It wasn't very useful. The...Continue Reading
Posted by Jack Crossfire | Nov 08, 2013 @ 12:11 AM | 3,727 Views
These were the rage in 2005, when LEDs 1st became powerful enough to provide useful camera illumination. People started thinking of uses for a ring of light around a lens. 3 years of collecting $1 flashlights resulted in this. It rapidly gets more expensive to make the LED density higher.

...Continue Reading
Posted by Jack Crossfire | Nov 06, 2013 @ 04:20 PM | 5,216 Views

Finally got floating point to work on the stm32F4. The PX4 source code had the 1st compiler flags anyone revealed that worked & they found the only toolchain that worked. The key flags are

-O2 -mcpu=cortex-m4 -mthumb -march=armv7e-m -mfpu=fpv4-sp-d16 -mfloat-abi=hard

The -fno-builtin flag has to be omitted, since some floating point operations use builtin functions.

The next step is getting the right math & gcc libraries, since the floating point functions depend on those. The libraries are different for each set of compiler flags, so PX4 gets the compiler to print the right libraries by running the compiler with full optimization flags & 2 hidden compiler commands:


After that, the linking used the same flags as without floating point:

-ffreestanding -nostdlib -nostdinc

with the fixed paths to libm & libgcc gotten from the hidden compiler commands. The executable is double the size.

More key points: the math library from the compiler directory has to be included. The following nugget has to be run in the bootloader before the program that links the math library is run:

static inline uint32_t getcontrol(void)
  uint32_t control;
  __asm__ __volatile__
     "\tmrs  %0, control\n"
     : "=r" (control)
     : "memory");

  return control;

static inline void setcontrol(uint32_t control)
  __asm__ __
...Continue Reading
Posted by Jack Crossfire | Nov 05, 2013 @ 10:48 PM | 2,504 Views

Finally cracked open a gearbox toy from It seems to be an east european toy.

It has exactly 2 gear ratios supplied by 2 sets of gears. 1:288 & 1:60

...Continue Reading
Posted by Jack Crossfire | Nov 05, 2013 @ 02:02 AM | 2,529 Views
After a 6 year run, decided to let expire. It'll be quickly taken by a squatter who will charge $80 million for it. Thus also ends any dealings with That site was annoying & painful.

Domain names get expensive, over time. added up to over $70 after 6 years. doubled the renewal price. has taken $156 over 13 years, but its price remaned constant. Unless you have a business, it's not worth it. The hobby domain names are now mostly owned by the generation which turned 20 when the internet just got started.

Posted by Jack Crossfire | Nov 03, 2013 @ 05:30 PM | 2,475 Views

It came across as a desperate bid to get money flowing into a business that was languishing in an era of no technology investment. Someone in a corner office finally said they needed money, so they staged a publicity campaign.

There's no logic to it. Airplanes don't need pilots anymore. There's no need for a plane to go fast without a pilot. It's a showpiece from an age when bragging rights mattered. Every spy plane development for the last 10 years has been smaller & slower. Insects are the future. Even then, all technology investment is in Asia.

They had some concept studies going on since 2006, but never received any funding for it. They had a time table that stretched to 2030 to finish it. They never said it could fly into space, though the media assumed it could. At mach 6, it could make a parabolic coast to the 120,000 ft range but it could never get to 328,000ft where space begins.

They brushed aside the problem of thrust. The turbine engine only goes up to mach 2.5. The scramjet only goes down to mach 4. They said it involved a black box that transforms from a turbojet to a ramjet to a scramjet. It would involve opening & closing various inlets & wank words.

Getting turbine engines to their current state took decades of trial & error. There is no algorithm to produce the optimum turbine engine. Someone thinks of a change to a compressor blade, simulates it, but the simulator can't dream up the change....Continue Reading
Posted by Jack Crossfire | Nov 02, 2013 @ 07:28 PM | 2,808 Views

After much tweeking, the XBee internet connection came in at around 32000 bits down & 6400 bits up. The upload packet rate maxed out at 44 Hz with the bandwidth weighted 5x towards downloading & 1x towards uploading. That was done by using 100 byte packets for downloading & 20 byte packets for uploading. Sending multiple download packets in between a slower rate of upload packets didn't work.

The browsing experience was pretty bad. Some pages with automatic refresh timers didn't load at all. It's interesting to compare how efficiently different pages load on a very slow radio. Facebook is very efficient. wunderground never loads.

The internet may seem extremely slow & bloated, but all that javascript & CSS modularization is probably more efficient than years ago. They're feeling pressure to optimize the page loading on phones.

Unfortunately, the XBee range was exactly the same as wifi. It would take either a repeater or a waveguide antenna. If the range was solved, the next step would be a system of ACKs that could handle dropped packets a lot more quickly than TCP.

The mane limitation with radios is they need a fast way to resend dropped packets. TCP is very slow to recover from dropped packets.