BlueM
What Is BlueM
BlueM project is no longer active.
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,
...or via external 9V battery.
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.
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.
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.
My Wifi solution
Starting out with an M100, and the goal of having wireless access to a TPDD device like LaddieAlpha for file access, here is my setup:
M100 with REX - REX contains a latency friendly version of NEWDOS (see below) Bluetooth adapter plugged into serial port (I use my BlueM device at 19200 baud - no flow control used or required
My Android Phone, running GetBlue software (an app I had to purchase) - GetBlue acts as a Bluetooth to TCP/IP bridge function - Once converted to TCP/IP, the traffic can go over Wifi or the cellular network - see setup configuration below - GetBlue is paired to my BlueM adapter - I provision GetBlue with the target IP address (either WAN or LAN), and port number 6785
My lab PC running LaddieAlpha - I create a virtual COM port, COM3, and I direct LaddieAlpha to that COM port - the virtual COM port receives TCP/IP traffic at port 6785 and forwards to COM3
For WAN access, - I configure GetBlue with my WWW IP address port 6785 - I create a hole in my home router firewall that forwards the inbound TCP/IP traffic - port 6785 is used, WAN router forwards to my target LAN IP address port 6785
For LAN access, - I configure GetBlue with my target LAN IP address port 6785
I believe same can work for T200, and PC-8201, provided you have a suitable copy of NEWDOS.
Feb 28 2015 update
Seems that we can have very short timeout, makes things a bit faster, if we switch source and sink.
Source: either a local IP address on my LAN (via Wifi) or a public IP address, port number 6785 (can be anything) Sink: BlueM module on the M100 (paired) Bidirectional: on Mode: RAW Timeout: 10 msec Size: 135 bytes
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.
Modified NEWDOS Source Code
This is a modification of Ken Pettit's NEWDOS version 5.02. I modified and tested it to work well with my system. This is a binary image for an OPTION ROM, loadable by REX. It was compiled using Virtual T.
| Model | Status | Source Files | Revision | Submitter / Date |
| M100/T102 | Beta | modified NEWDOS | 5.02 | Sadolph (talk) 10:53, 28 February 2015 (PST) |
for M100, to start NEWDOS use CALL 63013,2,X where the parameter X means X*100 msec of WAN latency tolerance. I use X=20.
Future direction
Since TPDD protocol is commonly used in M100 file access, and since it is inherently WAN friendly, and since flow control is problematic, the use of TPDD protocol into a general WAN transfer mechanism seems very promising. Adaptation in the Android bridge to TCP/IP gives data retransmission guaranteed across the WAN, so data loss potential is limited to the relatively high performance local network IE zero risk.
TPDD protocol could be the basis for a fully functioning "next gen BBS" for ModelT computers. It need not be limited to NEWDOS style file transfers; as a transport mechanism it can easily provide data transfer for other applications.
Future work therefor would be to build both a host and client application for next gen BBS that includes email, news, chat, classifieds, calendar etc. Perhaps the approach should be to take an existing serial BBS package and adapt it to TPDD protocol.
Comments welcome! lets discuss on the list!!
