Buy, Buy, Build, or Build

Sometimes there are just too many choices.

Recently I was looking for USB based temperature sensors. This seems pretty straight forward. And well, it could have been. The problem is that I needed them in a couple of different roles, and was looking at about half a dozen to 10 of them. I needed sensors inside of cases, and again in the top of the attic. At my disposal I've got programming skills, a soldering iron, and my AMEX card.

So, lets see if we can get a quick solution: buy.
Lots of vendors were willing to sell me solutions starting at around $129 that met my requirements. Well, most of my requirements. This would have way blown my budget. If I didn't see a need for more than 3... well, this post wouldn't be happening, and I'd instead be hitting reload on the shipment tracking page.

How expensive can this gear possibly be? Second solution: build.
Sensor, $1.50
USB/Serial, $4.00
Misc discrete components + cable: $5.00 tops
Packaging is limited, and with the discrete components, a circuit board is probably required, so, lets add another $10 for a schmartboard to make our lives easier. (Could have gotten one for $5, but then could have wasted a lot of time trying to fab my own to only save a couple of $ more. The goal was to have something working, not to spend a leisurely Sunday afternoon.)

Ok, this is not sounding too bad. Except that this solution requires that we bit-bang through the serial to the sensor. Doable, but lots of annoying programming. And lots of overhead on the host system. For each sensor.

There has to be a middle ground somewhere. And there is. www.raphnet.net handles a decent chunk of a middle ground, but still not perfect for all situations.

Raphnet has a couple of solutions. They use a Amtel microcontroller to drive the sensor chip and provide USB. It's an open source design, and they provide the firmware loads. Or Amtel's loaded with the firmware. Or an entire board with Amtel, connectors, logic. They even provide a USB to temperature sensor cable.

This is looking pretty good. This gives me the option of being able to buy cables that just plug in, or enough components when I have to build out a board anyway for the in-case sensors. (The project there requires buffer logic, connectors, and a 4-port USB hub chip anyway.) $35 a pop for the cables isn't too bad either.

Still, I poke around. Cheaper/Better?
Another build/buy option are the 1-wire devices. A little more expensive than if I was just buying one, it opens up some more options. The advantage here is that 1-wire is a bus technology. You buy a master, and then start adding sensors. A master can support anywhere from 100 devices to thousands, with up to a a couple thousand feet of cable connecting them.

www.embeddeddatasystems.com has a few products along this line. There are other vendors as well.

What really caught my eye was the ASCII based 1-wire interface. No bit banging, just send text to the serial port, and read text back. As a bonus, this is available as either a fully built external box, serial on one end, 1-wire on the other for $40. If I need to add it as part of a built board, they sell the core component on its own board for under $20. Temperature sensors start at $15 connected to a decent length of cable and neatly wrapped.

End result: some flexibility of solutions for putting sensors inside of cases, and for monitoring a full environment.

Buying the preloaded microcontroller, and other discrete components, for when I have to build a custom board anyway, is an obvious advantage. There is not much incremental cost when building out multiple boards. (Honestly, if it was just a in case one-off, I'd get a retail 4 port usb hub and just get creative with the cabling.)

Hooking up a half a dozen sensors wouldn't be fatal in either direction, but could potentially be cleaner with the 1-wire, especially since I need to make some long cable runs. The particular 1-wire interfaces lose their advantage when trying to make all the sensors appear as if they were system sensors. More traditional interfaces are available for a slight savings.

Having two, close solutions is a win. It means the focus can move on from "will it even work", to what will work best for this situation. It's time for me to order some hardware and start playing around.

mDNS

Getting mDNS nsswitch support is pretty straightforward under NetBSD.

1 Install the net/mDNSResponder-nss package.

2 Add "mdns" to /etc/nsswitch.conf on the host: line.

The package cheats and addes a symlink in /usr/lib pointing to the actual bits in the package base. Note: dig, host, and nslookup all talk DNS directly ignoring what libc sees. You're better off running ping(1).


Now, getting advertisement, another story. I've installed the net/mDNSResponder package. And it comes with no documentation. The package long description points one off to Apple's side and the opensource page for Bonjour.

It contains the following wonderful programs:
/usr/pkg/bin/mDNSClientPosix [listens and shows you whats out there]
/usr/pkg/bin/mDNSIdentify [Looks up a name, and probes system for info (needed ".local" appended)]
/usr/pkg/bin/mDNSNetMonitor [Another reporting tool, can target a host]
/usr/pkg/bin/mDNSProxyResponderPosix [args: IP NAME; registers another host with a mapping, also does services]
/usr/pkg/bin/mDNSResponderPosix
/usr/pkg/include/dns_sd.h
/usr/pkg/lib/libdns_sd.so [how did nsswitch know about this guy?]
/usr/pkg/sbin/dnsextd [implements DNS extensions supporting Dynamic DNS Update Leases and Long Lived Queries]
/usr/pkg/sbin/mdnsd [daemon, only a -debug flag]

End result:
mDNSResponderPosix -b -n `hostname`
works well enough to give my Macs dynamic visibility into the system. I dumped my in /etc/rc.local.

Limiting to certain interfaces would be nice, as would not having to specify the .local all the time, but well, I get that same behavior on my Macs.

DWL-900AP+

I've inherited 2 of these devices. The password was lost, and they were in some weird bridge configuration.

And none of the factory resets appear to work. Even tried multiple times.

Obviously the correct solution is to take them apart.

My searching has led me to the following URLs that showed some promise:
http://www.seattlewireless.net/index.cgi/SamSung4510
http://debugmo.de/ap.html

*sigh*
Almost 2 hours ago this started as trying to figure out if I was missing something wrt to getting a factory reset to work correctly.

Many URLs have lead to dead ends. (Not just no information, but 403s and 404s.)

Now its looking like these boxes are useless as even parts. The wireless card looks to be non-standard (some discussions lead that the pinout is the standard one, but they use a polled io method). They've only got 1M flash, and 8M of ram. (By contract the WL700g has 2/64 respectively.)

I'm considering just leaving these in a pile in case I need to salvage them for discrete components.

I suppose a password grind may now be in order for the unit I can even talk to.

Soekris Netbooting

So, I don't know exactly how I managed to set up the CF card the first time. But somehow I managed to get the NetBSD partition starting at sector 0 according to disklabel.

Jump forward a few months. I'm trying to build out a script to generate images for a CF card, and playing live with a card in the USB CF adapter. And, well, you already see where this is going.

Fortunately, I've only blown away the MBR. The firmware kicks back with no active partition and just stares at me.

I know. I'll netboot. On my ... OS X based Mac. No problem.

Some quick searching turned up mspo's page on netbooting a Soekris with NetBSD on OS X. ( http://www.mspo.com/soekris.html ) This page covered netbooting on NetBSD 3.0. I needed 4.0 on this box, so it shouldn't be much of a problem, right? Heh.

NetBSD 4.0 no longer has a pxeboot_ia32_com0.bin. This is the version of pxeboot_ia32.bin that is configured for serial console. The only documentation talks about using installboot to change parameters. I have no active 4.0 systems. I have no easy way to get any system to be a 4.0 system. And this was supposed to be a quick 1) netboot the netbsd-INSTALL kernel 2) change fdisk.

I just started off with the idea that building a cross toolchain so I could build a cross installboot under OS X was out of the question. Discussion with the developer who removed the _com0 variant was more helpful than the docs. It's possible to use dd(1) to rewrite the right pages in the pxeboot binary itself to adjust boot parameters. No instructions. No documentation.

I did the sensible thing: I used the pxeboot from 3.0.

Obviously this will eventually get deprecated. I've linked it here
http://labs.ono-sendai.com/p/aioDqqskX++stdGiqxIdFQ/

Long term, something better needs to be done with the NetBSD side of things. Time to open some bugs and hope I've got free time someday.

Back to my Soekris however. The fdisk in 4.0 doesn't want to let me play with setting the mbr partition to say that NetBSD starts at sector 0. Disklabel still shows 0 as the start point (there is code in NetBSD to handle the "disklabel part a starts at 0" case). And the a partition mounts fine. I just can't label the disk.

At this point, I'm getting further from my original goal of writing some code. I punt. I untar a bunch of the relevant bits (base, etc, comp, text .tgz's) onto the Mac and netboot a real kernel. A laid down source tree, and I'm golden.

End result:
Yeah, I need to keep a backup dev environment somewhere to deal with this sort of crap. It would have sucked less if I hadn't zorched the environment trying to build tools that would have allowed me to build other environments.

I'll worry about fixing that up after I've got a commitable version of the code I'm working on.