I’ve put information on how to communicate with the unit up here for future reference.

I found some information on an NI forum and on Matlab’s file exchange site.. The info on the NI site is a bit hard to read and not quite correct, so here’s a quick and clear rundown.

Serial Port Setup

If you’re using the USB cable, its actually just a virtual serial port, which will likely show up on your PC as COM1 to COM4. If you’re using the RS232 cable, then obviously you need a serial port on the PC. Either way, you need to set the serial port up for 2400 baud, 7 data bits, even parity, 1 stop bit, and no flow control.

Communication Overview

To read the temperatures from the unit, send this string over the serial port: “#001N\r\n”. Don’t include the quote marks. \r means the carriage return character (ASCII 13). \n means the newline character (ASCII 10). You’ll get back a string that follows this pattern: ” TTTTt TTTTtAB\r\n”. The first and second TTTTt groups represent the temperature and thermocouple type for the first and second thermocouple. The AB section is some miscellaneous information.

Temperature

The “TTTT” part will be a hexadecimal string representing the temperature in tenths of a degree Celcius. For example, ” 017A” represents 37.8 degrees Celcius. If the number is negative, it will start with a minus sign instead of a space. For example “-00C2″ means -19.4 degrees C.

Thermocouple Type

The “t” part represents the thermocouple type (set using the buttons on the HH506RA). The codes go as follows:

Miscellaneous Info

According to the document on the NI site, the “A” digit above represents Celcius/Fahrenheit while the “B” character represents battery. I’ve only ever seen them as 0 in my testing.

Example

Bringing it all together:
You send: “#001N\r\n”
You receive: “-00B20 02C1200\r\n”
Decoding: The first thermocouple is a type K that is reading -17.8 degrees C. The second thermocouple is a type T reading 70.5 degrees C.

Errors

If you send a bad command, you’ll get a a response of “Err\r\n”. I’ve found that to be a handy way to resynchronize communication in case something goes wrong. Just send “\r\n” and read for a response until you see “Err\r\n”. Once you get that response, you know the unit is ready to accept a command again.

Other Commands

The document on the NI forum has some additional details. For example, you can read the unit’s ID with the command “%IDR\r\n”. The ID is the set of digits you send in the read temperature command “#001N\r\n”. You can change the unit’s ID so that it responds to “#005N\r\n” by sending a command along the lines of “%001I005\r\n”. I don’t really see the point of this, so I haven’t bothered testing it. The unit can log data, which can then be read back with the command “#001S\r\n”.

I came across this article called on Embedded.com called “When good compilers go bad, or What you see is not what you execute“. I talks about all kinds of ways that compilers can end up generating incorrect (or sometimes technically correct but unexpected) source code. I’ve got a rule of thumb when debugging that in that vast majority of cases “you didn’t discover a bug in the compiler/operating system”. It’s good to keep in mind that that isn’t always the case.

One reference that especially caught my eye was to a paper titled “Volatiles Are Miscompiled, and What to Do about It“. They looked at 13 different C compilers and found out that all thirteen of them had issues with volatile variables.

Volatile variables are very frequently used in the embedded world. Memory-mapped hardware registers (used to read digital and analog inputs for example) are often accessed via volatile pointers in C. The volatile qualifier tells the C compiler “this variable could change at any time, so every time I ask you to read or write it, I really mean it!”

The authors of the paper found that every single compiler they tested failed to correctly implement the volatile qualifier in at least a few of their test cases. However, there are a few things you can do to help protect yourself:

• Don’t turn on optimization. They couldn’t prove it, but they’re pretty sure that all (and definitely most) of these kinds of bugs are caused by the compiler’s optimizer.
• Wrap uses of volatile variables in function calls. Because functions are (obviously) used way more than volatile variables, there tend to be very few bugs related to incorrect optimizations of function calls. Hiding volatile accesses in function calls makes it much less likely the access to a volatile variable will get optimized away (assuming the function isn’t inlined).
• Don’t use volatile variables for inter-thread communication, use semaphores instead. This one deserves a post all of its own.
• When the code just absolutely has to work, verify the assembly or machine code your compiler produces by hand.

One thing I really liked about the paper is that they used valgrind to help automate their testing. When I’ve run into some really tough to debug memory and pointer issues, valgrind has always been a huge help. I wish it were easier to use it in embedded programming projects.

The stats: 45 miles, average speed 13.1 mph (half a mph better than on last week’s 39 mile ride!), max speed 27.6 mph again (downhill of course), riding time 3h23, total time something like 4 hours.

Once you get off the bike path, people get a lot friendlier. I got a bunch of nods from other cyclists biking around Carlisle. While struggling my way up at 8-9 mph what the CRW site describes as a “mild rolling” hill I even got a big smile and a wave.

Click more for the map.

View Bike Route 2009-08-16 in a larger map

There’s all kinds of bicycle related physics here.

Also, did you know that to turn right on a bicycle (or motorcycle) you actually briefly turn the front wheel to the left? Steering left causes you and the bicycle to lean to the right, which then makes you turn right. This is called countersteering. You don’t even notice it at slow speeds because it happens automatically, but word is that it can save your life at high speeds.

I did my usual route along the Minuteman trail, but kept going when I got to the end (after a 2-3 minute break). There’s a cycling club called the Cambridge River Wheelmen that does some group rides in the Carlisle/Concord/Chelmsford area, so I just used one of their routes once I got to the end of the Minuteman.

One of the plusses of riding on rail trails is that they were designed for trains so they have nice and low grades. Roads are a different story. There were times when I was crawling up hills at 7 or 8 mph. On the brighter side flying down the hills at 30 mph is lots of fun.

Anyway, I ended up doing 39 miles in 3.5 hours (3 hours of pedaling) at an average speed of 12.6 mph. Next goal: 50 mile ride. Other goal: Pedal faster.

Map after the jump.

View Bike Route 2009-09-08 in a larger map

View Larger Map

View Bike Route 2009-07-03 in a larger map

Sure there’s a nice picture of the bike on the Gary Fisher website, but the crappy low-light iPhone picture proves it’s my bike.

My new bicycle, a 2009 Gary Fisher Wingra

Anyway, I got into Milan, and promptly got crapped on by a pigeon, for the fourth time. The pigeons definitely saved the best for last. I was walking along, when I all of a sudden felt something wet hit my hair. I thought "Goddam, that’d better be water," then stuck my hand into my hair. "Fucking shit," I mumbled, followed by "Literally!" I went to find something to wipe it off, but for some reason when there’s pigeon shit in your hair and you suddenly feel it start to ooze onto your forehead and towards your eyes, it suddenly becomes very hard to remember the Italian word for napkin. So, I ended up just saying "Scusi!!" at a sandwich stand and pointing at my head like an idiot until the woman got a horried look on her face, shoved some napkins at me, and pointed me to the bathroom. I swear, the next time I come to Europe, I’ll be buying some arsenic and mixing it with some pigeon feed.

My train was 45 minutes late leaving Milan, and I had a 30 minute connection to make once it got to Karslruhe. Fortunately, the Germans made up a bunch of time once they took it over, because I ran out of credit on my cell-phone while trying to call Dan to figure out what I was going to have to do to make to Metz before noon if I missed my connection (I needed to get there before noon to take my suitcase back from the office in my dorm).

I made it Metz early Friday morning, got my suitcase, rented a room for a night, and promptly passed out (I think I had slept two hours the night before). I ended up just hanging out, catching up on the news, and writing in my travelogue all day because my feet were incredibly sore and I really didn’t feel like going anywhere else.

On Saturday, I headed to Strasbourg, and basically did more of the same. Everyone had been telling me to read The Da Vinci code, and since I didn’t have anything better to do, I went to the bookstore to buy it. I couldn’t find it except in large-print, so I ended up buying Angels and Demons, the book that came before it. I also got myself my last cheap trappist beer (some Chimay blue… quality stuff). The book turned out to be incredibly good. It had a good plot, and it was really cool because it was set mostly in Rome, so I had just been to a whole bunch of the places it described a few days earlier.

And now here I am, in the Paris airport, waiting for my flight to Atlanta. The airport actually has little desks with power outlets, so people with laptops can use them before getting on their flight without draining their batteries. I thought I was going to have to find an outlet somewhere and sit on the ground, and here I am with a desk and padded stool. Anyway, that’s pretty much everything. I have to go back and fill a bunch of holes in my travelogue, some of which I’ll do now and some of which I’ll probably do back in Atlanta. After I’ve let thing percolate in my head a bit, maybe there’ll even be some deep thoughts that no one cares about except for me.