I do most of my development in Chromium, but noticed when I was testing my code for the new JSON responses, data wasn’t showing up properly in Firefox. I didn’t think much of it and figured I would return to the issue once I could focus on browser compatibility. I eventually, however, found myself at that point in development. I discovered that returning only a sliver of the normal response data lead Firefox to respond properly. I also found Chromium was hitting it’s own, significantly higher, limit. Firefox was capping the JSON response at 4096 bytes, whereas Chromium was somewhere in the area of 305kB. The Chromium limit was practically reasonable for my application, but there was no way I could dodge Firefox’s measly 4kB cap. But wait, there’s no way Firefox limits all AJAX responses to 4kB, right? Gmail can’t possibly operate on an army of tiny 4kB responses, so what am I doing wrong?

Courtesy of Firebug, I compared responses and noticed something peculiar, my server’s JSON responses contained the entire data contents in the headers of the response itself. After some Googling, it seems response header fields have a size limit. In Firefox that limit is, you guessed it, 4096 bytes. As I found, CakePHP’s automatic handling of JSON extensions takes the view variables and places them directly in the headers. Not only that, but my JSON views were returning the json_encode()’ed result of my data, so the response contained the same data in two places. Without much time available for finding a proper way to make Cake stop adding data in the headers, I decided to go back and do it the ol’ fashioned way, by myself. I got rid of Cake’s router line for Router::parseExtensions(‘json’); left my controller action alone, and changed my view to:

<?php
$this->layout = 'ajax';
Configure::write('debug', 0);
header('conten-type:text/x-json');
header('cache-control:no-store,no-cache,max-age=0,must-revalidate');
echo json_encode($results);
?>

And with that, both Firefox and Chromium now accept responses greater than 4kB and 305kB respectively. I’m still sprinting to finish this project, so I haven’t had time to investigate if the core Cake team knows about this issue. I plan to revisit after project launch and see if I can learn more about this strange behavior.

$res = ($primary)
	? &$result['MyModel']
	: &$result;

But for whatever reason, PHP fails with an “unexpected &” error after the ternary `?` operator. The ternary syntax is just a shorthand I use for a really easy if-then, so I decided to expand it and see what happens.

if($primary) {
	$res = &$result['MyModel'];
} else {
	$res = &$result;
}

This code runs without a hitch. So then what’s happening? Your guess is as good as mine. I honestly can’t discern what’s making PHP break on the ternary version. Although the ternary syntax is rather simple and can be considered synonymous to the if-then code, PHP seems to handle them differently and consequently breaks reference assignment when using ternary.

I expect that you have the Arduino IDE installed and running properly. This means the avrdude and avr-gcc libraries necessary to flash OpenLog will already be installed. Next step is to pull the firmware source code from the GitHub repository. If you don’t have git installed, run the following command:

$ sudo apt-get install git-core

Now you can run the git command to pull the source code over the read-only HTTP path. This is generally the easiest path to use to avoid issues with proxies or closed/blocked ports on your network.

$ git clone http://github.com/nseidle/OpenLog.git

Once the command has completed, you’ll have an OpenLog directory in your currently active directory. Time to compile the source code to make the required hex file that we’ll write to OpenLog.

$ cd OpenLog/Code/

$ make

You should see several notices about compiling various .c files, linking main.elf, and most importantly loading main.hex. Now we need to get that hex file onto OpenLog. Grab your trusty FTDI breakout board (you should never leave home without it) and wire it to OpenLog as shown below.

Before connecting the FTDI to your computer, we want to make sure we have the correct device path for the next step. Look at the list of all tty-capable USB devices. It’s okay if none show up right now.

$ ls /dev/ttyUSB*

Now connect the FTDI board and run the command again. The new ttyUSB# device listed is your FTDI board. I’ll use ttyUSB0 in the command below, so you will need to change the zero if your # is different.

I hope you have an extra wire at hand. The Linux build of avrdude unfortunately doesn’t have the “DTR wiggle” necessary to automatically reset OpenLog’s ATMega328p, so we have to do it ourselves. Grab a wire and connect one end to ground. If necessary, the microSD socket’s case can be used as a ground if you don’t have OpenLog on a breadboard. You’ll need to tap the other end of the wire onto the GPIO pin 6 on OpenLog. This is the square pin pad near the “O” in “OpenLog” on the silkscreen (the bottom-left most pin in the image featured above). Timing here is of the essence; run the command below, hit enter on your keyboard, then immediately tap the other end of your grounded wire to pin 6. Don’t leave the wire sitting on pin 6, it’s just a quick tap to momentarily ground it and force a reset.

$ avrdude -p atmega328p -P /dev/ttyUSB0 -c stk500v1 -b 57600 -U flash:w:main.hex

Don’t forget to change the ttyUSB# number if necessary. If your timing was good enough, you should see avrdude show a progress bar as it flashes the hex firmware onto OpenLog. If not, you’ll likely see errors like “programmer not responding” or “out of sync”. Try try again. Tapping enter and grounding pin 6 should be almost instantaneous, with the enter key coming ever so slightly first.

After a few seconds, the updated firmware will now be on your OpenLog chip and you’ll be on your merry way. I hope this helps someone out there.

Consider the following snippet of code:

<?php
$a = array(
     0 => "test {$a[1]}",
     1 => "blah {$a[2]}",
     2 => "argh"
);
echo $a[0]."\n";	// outputs: test

$s2 = "argh";
$s1 = "blah {$s2}";
$s0 = "test {$s1}";

echo $s0."\n";	// outputs: test blah argh
?>

At first, we attempt to use an array to handle the string recursion, then we use string variables.We can see from the output that the array code simply doesn’t work. It appears you can’t access parts of the array from within itself. At the moment, it looks like I’m stuck avoiding arrays for this. If anyone out there knows a way around this, please let me know!