BlueM

From Bitchin100 DocGarden
Jump to navigationJump to search

What Is BlueM

BlueM is a bluetooth adapter custom designed for M100/T102/T200 and PC-8201. It is based on the RN-42 bluetooth module from Roving Networks.

BlueM may be ordered with one of two power options - either directly powered from the M100 via BCR port,

BlueM 1.jpg

...or via external 9V battery.

BlueM 2.jpg

BlueM 3.jpg


Since BlueM is really just a repackaged RN-42, here is the instruction manual. Keep in mind REX ships with the serial port pre-set to 19200 8N1.

RN-42 manual


Also note, that the RN-42 does not listen to XON/XOFF flow control protocol, and will overrun TELCOM with data when trying to interface with the built in commands. HTERM, developed by John Hogerhuis, uses hardware flow control and is ideal for managing the RN-42/BlueM. This version of HTERM runs at 19200, but is not current with John's main development.

HTERM for M100/T102/T200


Experiences with Bluetooth

I've used my BlueM quite a bit, but as a direct replacement for a serial cable it has it's limitations. I have noticed that around the house, it is fairly reliable, but due to the low signal power, I find it often struggles to maintain connectivity.

My initial use was to connect my M100 to a PC running LaddieAlpha. There are a number of things to be careful of though-

1) latency. Bluetooth introduces some significant delay due to the adaptation of the data on and off the radio channel. The DOS running should be delay tolerant. I have found that Teeny is pretty delay tolerant. REX is also fairly latency tolerant. TSDOS is NOT latency tolerant; late versions of NEWDOS are specifically latency tolerant enough to tolerate wide-area latencies as well.

2) packetization. The serial data as it emerges the M100 has it's own pace. Bluetooth has to decide how to chop it up and forward it as packets.. which introduces some breaks in the flow. I don't know a lot at this time about how it buffers and plays out data. So, both ends of the bluetooth link need to be tolerant of 'packet' 'jitter'.

3) Flow control: gotta pay attention to flow control. Either the serial traffic is so slow as to never overrun the tiny M100 buffer, or you have to use flow control. Some bluetooth adapters obey XON XOFF control (preferred) while others support hardware flow control CTS/RTS, while others support none. Bluetooth radios buffer a lot of data potentially, so a lot of data can be lost when the M100 is signalling to STOP and the radio ignores it's pleas.

4) TPDD protocol: TPDD protocol is a handshake based mechanism for data transfer and since the maximum transfer per handshake is 128 bytes, there is never a chance of buffer overrun. This makes TPDD protocol ultimately friendly for WAN purposes, but it suffers the traditional 1/x performance reduction as latency increases.


Overall, BlueM worked well when combined with a simple bluetooth adapter for the PC line the ASUS BT-211, in combination with LaddieAlpha.

Experiences with Wifi and WAN

My secret goal of course has been to enable wifi connectivity. Recently a key missing piece of the puzzle became apparent - an Android app that enables a phone to act as a bluetooth bridge onto IP (either Wifi or LTE/4G). That app is called GetBlue, and I highly recommend the software.

Using GetBlue, I have been able to redirect serial data from the M100 onto Wifi, and then subsequently across my LAN and gateway router, out into the wilds of the public internet. This has been especially interesting as I can ultimately connect the M100 using NEWDOS to connect to a remote LaddieAlpha instance.. enabling remote file transfer.

Details

GetBlue allows the operator to define a target IP address and port number for setting up a bi-directional TCP transfer between a Bluetooth source and a remote host. Settings that I use for GetBlue:

 Source:  BlueM module on the M100 (paired)
 Target:  either a local IP address on my LAN (via Wifi) or a public IP address, port number 6785 (can be anything)
 Mode:  RAW
 Timeout: 110 msec
 Size:  135 bytes

The LaddieAlpha target is a serial application; to make it accessible on the IP network you need to create a virtual serial port in the host PC. I used

 http://www.hw-group.com/products/hw_vsp/hw_vsp2_en.html

as a solution for bridging a specific port on my PC to a virtual COM port. Then LaddieAlpha can be started referencing that virtual serial port. Lastly, when needed to allow inbound WAN traffic to reach that LaddieAlpha instance, I have to open up a port on my Router to forward specific port traffic (6785) to the specific PC port where LaddieAlpha is running.

In this manner I have been able to establish a NEWDOS session across Bluetooth to my android phone, then onto the public IP network, and then ultimately across the public IP network to my home router and on to LaddieAlpha. The round trip latency including all the buffering and delays was about 300-400 msec I believe.