Connetcing to preprogrammed TI Launchpad demo under Linux

TI Launchpad board comes with preprogrammed demo application for temperature sensing which is touted to output temperature values to host via USB-encapsulated UART. By connecting to it via terminal you can see that it indeed sends something, but that doesn't look anything like temperature represent in ascii digits, like someone naively could expect. It turns out that it's well kept secret on Launchpad wiki pages how to make sense out of it - at least, you get advertisements for CCS and Java-based GUIs to read out the output, but not straight docs of how to use builtin demo without all those crutches. So well, wrong approach - it's your random user-friendly arduino, approach of reading docs doesn't work here, better go straight to the source.

And, here's step by step instructions:

First thing to note is that Launchpad's UART-via-USB emulation is extremely fragile. It seems that if MCU started to produce UART output but host doesn't read it out, then buffer in USB bridge just gets overflowed and it stops responding to USB. So, if you want to get it working, follow each step below precisely and if any issue happens, restart from beginning (with unplugging LaunchPad).

1. If you have plugged LaunchPad into USB, unplug it now to make sure you start with properly reset device.
2. Plugin the board into USB, general-purpose green and red should blink interchangeably. The demo app doesn't yet sense temperature or sends it out yet in this mode.
3. Execute stty 2400 -F /dev/ttyACM0 . That's right - the demo app communicates at 2400 bit/s data rate and using any other rate will produce garbage input. (One reason for such low speed is that LaunchPad's MCU actually doesn't have hardware UART, it is emulated in software).
4. Run hexdump -v -C /dev/ttyACM0 . It shouldn't produce any output yet.
5. Press GPIO button. The demo app goes into measurement mode and starts to send out temperature in Fahrenheit as raw bytes over UART. Try to heat/cool air around the board to see values change.

Sample output:

00000020  60 60 60 60 60 60 60 60  60 60 60 60 60 60 60 60  |````````````````|
00000030  60 60 60 60 60 60 60 60  60 60 60 60 60 60 60 60  |````````````````|
00000040  60 60 60 60 60 60 60 60  60 60 61 60 60 61 60 60  |``````````a``a``|
00000050  61 60 60 61 61 61 60 61  61 61 61 61 61 61 61 61  |a``aaa`aaaaaaaaa|
00000060  61 61 61 61 61 62 61 62  62 62 62 62 62 62 62 61  |aaaaababbbbbbbba|
00000070  62 62 62 62 62 62 62 62  62 62 62 62 62 62 62 62  |bbbbbbbbbbbbbbbb|
00000080  62 62 62 62 62 62 62 62  62 62 62 62 62 62 62 62  |bbbbbbbbbbbbbbbb|

Bluetooth Park Mode Exposed

So well, as I settled on Bluetooth as a wireless sensor/automation protocol and grow my device base, I started to wonder what will happen when I'll have more than 7 slave devices. Bluetooth stack of master device (Bluez in our case) must be smart to put devices into and out of PARK mode to allow to communicate with more than 7 devices, right? Not in this world.


Not only Bluez doesn't support park management, according to Marcel Holtmann, the problem is that it's really not known if there're devices (masters) which can support more than very limited number of slaves, or even have decent park mode implementation at all:

• http://article.gmane.org/gmane.linux.bluez.devel/287
• http://article.gmane.org/gmane.linux.bluez.user/3813
• http://article.gmane.org/gmane.linux.bluez.user/3815
• http://article.gmane.org/gmane.linux.bluez.user/6032
• http://article.gmane.org/gmane.linux.bluez.user/12689
• http://article.gmane.org/gmane.linux.bluez.user/12719
• http://article.gmane.org/gmane.linux.bluez.devel/13135

Anyway, I started to test parking with devices I have.

HC-04 Bluetooth module with CSR BlueCore4-Ext

# hcitool cc 00:11:10:xx:xx:xx; hcitool con

Connections:
    < ACL 00:11:10:xx:xx:xx handle 12 state 8 lm MASTER

What we need here is a connection handle 12 (0x0c). hcitool doesn't have dedicated command for part mode (and for lot of other things), so we'll use raw HCI command mode using "cmd" command:

# hcitool cmd --help
Usage:
    cmd <ogf> <ocf> [parameters]
Example:
    cmd 0x03 0x0013 0x41 0x42 0x43 0x44

What's important here is that <parameters> should be byte values. If words should be given as parameters, they should be give by bytes in little-endian format.

# hcitool cc 00:11:10:xx:xx:xx; hcitool cmd 0x02 0x05 0x0c 0 0x50 0 0x40 0

Here we run HCI_Park_State(Connection_Handle=0x000c, Beacon_Max_Interval=0x0050, Beacon_Min_Interval=0x0040) command (see Bluetooth spec). And here's communication as captured by hcidump (parts irrelevant to park command omitted):

2012-01-07 15:36:46.084074 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 15:36:46.086040 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 15:36:46.271047 > HCI Event: Mode Change (0x14) plen 6
    status 0x24 handle 12 mode 0x00 interval 0
    Error: LMP PDU Not Allowed

This "LMP PDU Not Allowed" was quite confusing and took me lot of googling to figure out. Fortunately, I found insightful post from a CSR guy right on this matter: http://article.gmane.org/gmane.linux.bluez.devel/72

What we get here is that local Bluetooth master just forwards status it got from the remote device. As the message suggests, park might be disabled in remote device line policy. Let's see:

# hcitool cc 00:11:10:xx:xx:xx; hcitool lp 00:11:10:xx:xx:xx
Link policy settings: RSWITCH HOLD SNIFF PARK

Here's slight issue of what hcitool lp actually does. According to man, it "displays link policy settings for the connection to the device with  Bluetooth  address". There's also "hcitool lp" command which "Sets default link policy". So, reasonable assumption would be that every device may have default link policy, then during connection, they negotiate link policy which is suitable for the connection. Ok, let's set PARK policy explicitly:

# hcitool cc 00:11:10:xx:xx:xx; hcitool lp 00:11:10:xx:xx:xx PARK; hcitool lp 00:11:10:xx:xx:xx; hcitool cmd 0x02 0x05 0x0c 0 0x50 0 0x40 0
Link policy settings: PARK
< HCI Command: ogf 0x02, ocf 0x0005, plen 6
  0C 00 50 00 40 00
> HCI Event: 0x0f plen 4
  00 01 05 08

But hcidump shows the the same "LMP PDU Not Allowed" error. So, what we have is that HC-04 module advertizes park support, it apparently negotiates its availability for connection, but when asked to actually perform it, it rejects it. This is so much correlates with this message: http://article.gmane.org/gmane.linux.bluez.user/12710

PS3 Bluetooth remote

# hcitool info 00:06:F5:xx:xx:xx
Requesting information ...
    BD Address:  00:06:F5:xx:xx:xx
    Device Name: BD Remote Control
    LMP Version: 2.0 (0x3) LMP Subversion: 0x229
    Manufacturer: Broadcom Corporation (15)
    Features: 0xbc 0x02 0x04 0x38 0x08 0x00 0x00 0x00
        <encryption> <slot offset> <timing accuracy> <role switch>
        <sniff mode> <RSSI> <power control> <enhanced iscan>
        <interlaced iscan> <interlaced pscan> <AFH cap. slave>

So, this fair Broadcom device doesn't even conceal the fact that it's barely Bluetooth interoperatable - it doesn't support park state at all.

No surprises when asking it to go there nontheless:

2012-01-07 16:03:08.863586 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 13 max 80 min 64
2012-01-07 16:03:08.865636 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x1a ncmd 1
    Error: Unsupported Remote Feature / Unsupported LMP Feature

LG KS20 WindowsMobile phone

# hcitool info 00:1E:75:xx:xx:xx | grep park
        <park state> <RSSI> <channel quality> <SCO link> <HV2 packets>

So, this one advertizes park. But:

2012-01-07 16:29:11.288514 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 16:29:11.290485 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 16:29:11.466508 > HCI Event: Mode Change (0x14) plen 6
    status 0x0c handle 12 mode 0x00 interval 0
    Error: Command Disallowed

Broadcom is such Broadcom...

Huawei U8160 aka Vodafone 858 Smart Android phone
# hcitool info 04:C0:6F:xx:xx:xx | grep park

<empty>

2012-01-07 16:19:01.322536 < HCI Command: Park State (0x02|0x0005) plen 6

    handle 12 max 80 min 64

2012-01-07 16:19:01.324521 > HCI Event: Command Status (0x0f) plen 4

    Park State (0x02|0x0005) status 0x1a ncmd 1

    Error: Unsupported Remote Feature / Unsupported LMP Feature

Broadcom is such Broadcom...

HTC Mogul WindowsMobile phone

2012-01-07 16:11:14.184067 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 16:11:14.186430 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 16:11:14.528429 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x03 interval 80
    Mode: Park

Bwahaha! TI rules!

Samsung i740 WindowsMobile phone

Manufacturer: Cambridge Silicon Radio (10)

2012-01-07 17:54:17.141466 < HCI Command: Park State (0x02|0x0005) plen 6
    handle 12 max 80 min 64
2012-01-07 17:54:17.142911 > HCI Event: Command Status (0x0f) plen 4
    Park State (0x02|0x0005) status 0x00 ncmd 1
2012-01-07 17:54:17.472919 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 12 mode 0x03 interval 80
    Mode: Park

Linux computer with Broadcom chip

Park mode work here, supervised by Bluez.


So, out of 7 devices (that's whole piconet, and I have more!)  only 3 supported park mode.


More insightful posts:

• http://article.gmane.org/gmane.linux.bluez.devel/291
• http://article.gmane.org/gmane.linux.bluez.user/3834

Notebook MSI X430 (aka X420 aka X410) - Big Disappointment

So, I've been shopping for notebook for some time - my current work model, HP Compaq nx9420, has been failing me for like 1.5yrs now, with its lid hanging on just one corner (the steel support plate in there broke, nice job, HP!). I also grew pretty tired to carry it's 3.3kg around, so was shopping for subnotebook. So, criteria was: minimal weight, workable screen size (12" is kinda small, 14" is kinda heavy, those are extreme bounds), budget price (also tired to shell out a grand+, especially that nx9420 shows that no matter how much you pay, you have strong chance to get budget quality nowadays).

I had Acer Timeline t3810 (or something close) in my shopping list, but was swamped by real world, so when I came closer to actual shopping - oops, that model is no longer available. That's another trait of modern hardware market - it's not like good stuff gradually becomes cheaper and better stuff comes in, it's like good stuff being replaced by more expensive and mediocre one.

So, I started looking for another replacement, and I found MSI X430. Gosh, it was brilliant. They cramped 14" in 1.5kg - there was/is no competitor in that regard. Battery life was crap (~2hrs), but that's actually brilliant engineering thought. Because laptop battery doesn't last "X or Y hours", it lasts untill next hot summer - when it completely dies. So, it makes little sense to pay lot for large battery which will anyway die soon. So, thanks to that nice crappy battery, X430 costed just $500 (my ideal upper bound for a contemporary piece of technical stuff), it made decent weight to of course. The performance wasn't great, but at least it had latest AMD X2 which has come to these vicinities, L335.

Guess what - when I started to actually call shops, it turned out the model went out of stock like a week ago. Yes, it was on hot sale the whole summer, and boom, suddenly there's only X410 & X420 which are less performance and/or much more pricey. Well, I waited a bit, and oh, miracle - one shop got it back.

Got it in a day, just to find out that:

1. Max amount of memory ambgiously (not explicitly) mentioned in the docs is 2Gb. Come on, this is not netbook, which 2Gb?? And it doesn't have dedicated RAM cover to easily try 4Gb module - would need to disassemble it completely (either void warranty or go to service center - with what - 4Gb SODIMM I purchased not knowing if it works or not?)
2. Booted Ubuntu 10.10. Got complete mess on the screen, more specifically torn off signal sync. Remember how old CRT TVs looked with broken row sync heterodyne? I couldn't even imagine that effect can be so faithfully reproduced on LCD panel! I was able to found just single report of someone else facing that, did some hacking, found a workaround, and then thanks to DRM driver people found easy solution. So, well, that DRM/Ubuntu issue, though, taking into account all points above and below, MSI engineers outwitted themselves too. (Support for such funky videoadapeters, as in X430, will be (was) fixed in next kernel version).
3. One final point which really put me over the edge and made me return the thing. Its touchpad doesn't support scrolling. Well, to be exact, it does, in a following manner: you have to tap at top right corner to scroll up, somewhere near bottom right corner to scroll down. So yes, you had to target the tap, and target pretty carefully, requiring an eye-look. How that compares with familiar blind swipe near the right side? If that sounds like a petty complaint, you've got to use that yourself! Remember, I started all ecstatic about the box, and that dissatisfaction grew subconscious ways. It's like making you walk on the knees. Many people would say "So what? Connect any mouse you like, voila!" Well, but I'm buying a subnote to be light and lean and not carry extra stuff, and still being able to use it comfortably. If to start bringing around crutches everywhere, why bother with lack of selection, higher price, lower performance of subnote? Well, I started to drop into any notebook shop I saw in city motion and know what - all notebooks out there have sane touchpad scrolling, newer ones brag about multi-touch (2-finger) scrolling with stickers, couple of MSI models were the only ones with such brain-dead scrolling. I finally made a search over the Internet. And found dozen-of-pages hate-topics regarding MSI's touchpads. People go by any length to do something with them, like soldering out that thing and solder in normal touchpad.

So, the last issue and discoveries regarding it really freaked me out. What vendor's attitude could be regarding putting unusable and disturbing human interaction hardware into otherwise noticeable models (again, not all MSI notebooks are affected, it seems that subnotes are primary target). The most realistic would be "models are cheap, hence cheap hardware". But that's some $5, really, and that difference makes the computer unusable! So, simple answers don't cut. The must be some conspiracy theory. Like, MSI bought those broken touchpads in millions for $0.5 each, and puts them out to clear stock, wildly ignoring user complaints. Or MSI was bribed by touchpad vendor. Or that they have attitude like "We make few cool points, so no matter what other crap we put there, you'll buy it".

No, I will not. I'm not keen on returning stuff, but that box went back to the shop. And I even wrote this blog post ;^).