Handheld Serial Programming: USB or Wireless

[Kingfish]

whereswally606: Thanks buddy. Sometimes I feel like... like I'm writing in a dark urban cave (and well, I yam) - so friendly support always helpful

johnamon, I think we’re back to the issue of porting an application written for desktop to portable device for that to work.

Just to clarify my path:

• There is python-for-android development. However I do not program in that language, so modifying the source code for a port over is not practical.
• I do know .NET/CSharp quite well. Mono (for Android and for iPhone) can accept applications written for Windows.Forms with some small caveats. I’m writing in WPF because I dislike Windows.Forms, and really – it’s all window dressing anyway (pun intended). I am writing the code with the intension that it can/should/will be code-signed safe; so that you can d/l it from the Marketplace because I don’t know of another trusted route that is so terribly easy to use.
• Adding Bluetooth (BT) code solves two problems: I am writing code that I trust (with fingers crossed) will be able to have a wireless two-way file transfer between my desktop and phone. Natively, Windows doesn’t want to communicate with Android or anyone else except itself; I can respect that: They don’t want to hand the keys over to the competition, though they are also not stopping you from trying – and that’s the way it should be. So… after today I hope to dabble in some BT waters and resolve the issue (as others have before me).
• Once the code works -> we port over to a platform that supports multiple devices: Desktop, smartphone, tablet… Arduino? I don’t know about that well enough to say. But as one engineer to another: Anything is possible :wink:

Drat: Empty cup & pot. Not spilling a single bean this time…
Happy Friday, KF

 

[Arlo1]

I worked very hard on some USB stuff about 8 years ago. I think I will order a board like Bigmoose got and try it again.

 

[johnamon]

I worry that the software porting and bluetooth implementation will be so difficult that the project will get bogged down due to being 'too difficult'

To clarify my idea - I would not attempt to port software to the arduino, rather write a simple menu system that contains the 20 or so variables to be set - and construct the serial string manually - this will be very very easy and easy for others to repeat.

Screen and button for menu navigation can be achieved with something like this

Anyway, it would be very very cool if you get this working, however you do it 8)

 

[Kingfish]

Before I started this project my brain only had two folds:
The one that separates left from right, and the other that cleaves the frontal lobes from the rear.

The effort has certainly put a new wrinkle on that otherwise clean-pressed flannel membrane that was otherwise used to filter beer.

But I think I’m well-past the difficult part which is sitting down and writing the first few lines, and sticking with it past Noon on Day-0. There will always be crisis when programming; it’s just a matter of slicing off a manageable chunk and chipping away at the problem until it is resolved. Then grab another chunk and do the same. Pretty soon, there’s nothing left to do but show off the prize – and wait for critique… which always comes. In this way, men become like women and suffer postpartum, but I digress.

Deep in conception with no turning back, KF

 

[bigmoose]

My board came this morning. No instructions, nothing... just like yours. I'm going to go down to the lab and power it up... see if the stack magically communicates with my phone! Yea right...

 

[bigmoose]

KF, Took my module and powered it up to 5 volts. Turned on the Bluetooth on my android. Phone found the module and paired using the 1234 module code. Module showed up as "Linour" I loaded "Bluetooth Terminal" from the apps store, a sort of hyperterminal for the android. Hooked the scope up to the RS232-TTL level output of the bluetooth module and what did I see, but 8n1 characters being pumped out!

This approach of yours definitely has potential!

 

[Kingfish]

Whoo hoo!

You didn't have to fuss with a password or any other setup?

Glad that part was painless.

I've been doing far too much rote cut & paste this afternoon to the point that it was putting me to sleep. I dislike drudgery. Decided to break from that and work on UI concepts; all part of the larger picture.

Thanks for checking that out BigMoose - much appreciated 8)
Cheers, KF

 

[bigmoose]

When I paired it, I don't think it took the first time. I entered 0000 for the pairing code. First time seeing all those small print pop ups I likely missed the "not paired" that was likely in Spanish... I was dithering wondering why it wouldn't send. I had to go to Google translate, and found it said it "couldn't find a module" so I repaired it using 1234 pairing code, and that time it definitely said it paired.

I then loaded an English language android terminal program and away we go. Been working since.

 

[Kingfish]

Cool. I figured the passcode would be something like 1234 or abcd. Nice security level protection, huh
Kinda makes you a believer in not keeping these devices connected.

I worry about the File Transfer part from Desktop to Mobile and back again. Fortunately we're just passing 0-9 and a few other characters. Even at 9600 baud - we're done in < 0.1 seconds.

~KF

 

[Kingfish]

Status:
Briefly – there are two models of controller boards that I had originally intended to support: EB2XX and EB3XX. The WPF CSharp interim application I've been working away on can now flash to an EB3XX series board successfully. The data coming out of the application is identical to the XPD application. Much voodoo and witchery was required, and many commas, were,, enslaved,,,

<20130320174803.048 SYS>
COM is open
<20130320174803.062 SYS>
Baud rate 38400
<20130320174803.065 SYS>
RTS off
<20130320174803.068 SYS>
DTR off
<20130320174803.071 SYS>
Data bits=8, Stop bits=1, Parity=None
<20130320174803.075 SYS>
Set chars: Eof=0x1A, Error=0x00, Break=0x00, Event=0x1A, Xon=0x11, Xoff=0x13
<20130320174803.079 SYS>
Handflow: ControlHandShake=(), FlowReplace=(), XonLimit=128, XoffLimit=128
<20130320174803.083 SYS>
Baud rate 38400
<20130320174803.086 SYS>
RTS off
<20130320174803.089 SYS>
DTR on
<20130320174803.092 SYS>
Data bits=8, Stop bits=1, Parity=None
<20130320174803.096 SYS>
Set chars: Eof=0x1A, Error=0x00, Break=0x00, Event=0x1A, Xon=0x11, Xoff=0x13
<20130320174803.100 SYS>
Handflow: ControlHandShake=(DTR_CONTROL), FlowReplace=(), XonLimit=128, XoffLimit=128
<20130320174803.102 SYS>
DTR on
<20130320174803.107 SYS>
Baud rate 38400
<20130320174803.110 SYS>
RTS on
<20130320174803.113 SYS>
DTR on
<20130320174803.116 SYS>
Data bits=8, Stop bits=1, Parity=None
<20130320174803.120 SYS>
Set chars: Eof=0x1A, Error=0x00, Break=0x00, Event=0x1A, Xon=0x11, Xoff=0x13
<20130320174803.124 SYS>
Handflow: ControlHandShake=(DTR_CONTROL), FlowReplace=(TRANSMIT_TOGGLE, RTS_CONTROL), XonLimit=128, XoffLimit=128
<20130320174803.127 SYS>
RTS on
<20130320174803.127 SYS>
Set timeouts: ReadInterval=-1, ReadTotalTimeoutMultiplier=-1, ReadTotalTimeoutConstant=200, WriteTotalTimeoutMultiplier=0, WriteTotalTimeoutConstant=0
<20130320174803.130 SYS>
In/out queue size 4096/4096
<20130320174803.138 SYS>
Purge the serial port: TXABORT, TXCLEAR
<20130320174803.140 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.142 TX>
8
<20130320174803.197 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.197 TX>
8
<20130320174803.251 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.252 TX>
8
<20130320174803.307 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.307 TX>
8
<20130320174803.361 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.361 TX>
8
<20130320174803.414 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.415 TX>
8
<20130320174803.468 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.469 TX>
8
<20130320174803.522 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.523 TX>
8
<20130320174803.576 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.577 TX>
8
<20130320174803.630 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.631 TX>
8
<20130320174803.684 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.685 TX>
8
<20130320174803.738 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.739 TX>
8
<20130320174803.792 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.794 TX>
8
<20130320174803.846 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.847 TX>
8
<20130320174803.899 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.900 TX>
8
<20130320174803.953 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174803.954 TX>
8
<20130320174804.007 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.008 TX>
8
<20130320174804.064 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.065 TX>
8
<20130320174804.117 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.118 TX>
8
<20130320174804.170 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.171 TX>
8
<20130320174804.224 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.225 TX>
8
<20130320174804.277 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.278 TX>
8
<20130320174804.331 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.332 TX>
8
<20130320174804.384 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.385 TX>
8
<20130320174804.437 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.438 TX>
8
<20130320174804.490 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.491 TX>
8
<20130320174804.543 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.544 TX>
8
<20130320174804.596 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.597 TX>
8
<20130320174804.652 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.653 TX>
8
<20130320174804.705 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.706 TX>
8
<20130320174804.758 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.759 TX>
8
<20130320174804.811 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.812 TX>
8
<20130320174804.864 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.865 TX>
8
<20130320174804.917 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.918 TX>
8
<20130320174804.970 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174804.971 TX>
8
<20130320174805.023 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174805.024 TX>
8
<20130320174805.076 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174805.077 TX>
8
<20130320174805.129 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174805.130 TX>
8
<20130320174805.179 RX>
KKKKKÿ
<20130320174805.182 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174805.183 TX>
8
<20130320174805.185 RX>
U
<20130320174805.240 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174805.241 TX>
<STX><SI> <DC1>ž<NUL><NUL>D)_<ETX>–<SOH><SOH><BS><NUL>ÿ<NUL><NUL><NUL><SOH><NUL>_<NUL>9<NUL><ETX><NUL><NUL><NUL>é
<20130320174805.251 RX>
QR
<20130320174805.297 SYS>
DTR off
<20130320174805.300 SYS>
Purge the serial port: RXABORT, RXCLEAR
<20130320174805.303 SYS>
Purge the serial port: TXABORT, TXCLEAR
<20130320174805.312 SYS>
COM is closed

Typical Serial output by the WPF application. The character "8" is used to ping the controller until we hit the switch.

Now the bad news…
Actually it's not bad; it's sad. I do not have a valid EB212 test victim in my possession: They have all been fried or recycled and replaced by the later EB312 model. However the WPF application does output the data – in theory.

Did a bit of digging about and I found an older board of the EB812 series; remember those from about 3 years ago? I used the Parameter Designer For 116-EnglishV2.exe and although the board has other circuit issues – I can still flash it. The salient question:

• Is there any interest in supporting this series of controller boards. If so – I shall twiddle away at a point in the future to make it so.

Flashing to the Controller (albeit a late model) was the first chief milestone – although the general opinion from the peanut gallery was that it was more of a millstone. Very very v e r y V E R Y oh so vvvvvvaaaaarrrryyyy tedious work. But – I got it! Believe me – I know more about how to take an ASV file and convert it into binary that I had ever cared to know.

Now the real work begins and that it adding in Bluetooth functionality.

• First we want to recognize any BT device.
• Considering the work on the Serial Port was a great leap towards this goal – I think I’ll hit that one next.
• Then we’ll try to connect to a non-Windows smartphone in hopes of pushing/pulling files to and fro.
• Once that’s done – we rewrite it all over again in Mono (being the best possible candidate) for cross-platform.

Donations are accepted!
Yes yes, I accept pints and gallons of goodly beer should you have extra. No amount is too small; as long as it’s fresh – it will be consumed. So donate today to the thirsty kindred developer living in a very dark cave in the side of a hill in Redmond where it rains… well – it always rains.

Eventually – when we get around to testing, I’ll ask for vic… er, volunteers for testing the flashing aspects via BT and USB. 8)

Thank you for your humble interest. Encouragement is also welcomed ...for I am certainly encourageable :wink:
Empty glass. KF

 

[Kingfish]

Bluetooth – a fireside chat:
I just spent the last couple of days drilling into BT. But it wasn’t until later this morning that I realized my built-in BT service wasn’t working properly. More in a bit.

In itself – the BT codebase is gigantic; I have the BroadCom (WIDCOMM) DK installed and have gone through the x86 code in some detail trying to come to grips with the entire enchilada …which is more like chimichanga with a side of chicken mole dinner …in farmer’s portions. When I tried to compile the kit - some of the references were missing, even though the last revision less than 9 months old.

Eventually I figured out that I couldn’t get any application to see my embedded BT device. This turned into a larger witch hunt that fingered Dell Support – and lack thereof. Finally I realized the hardware was not working at all, but tracked down the latest drivers for my system - released in 2009; Installed that and – whala: I have BT Radio! The drivers were pretty stale but I had the latest from BroadCom (d/l’d today) and did the lil’ Device Manager upgrade w/o a restart.

Using BT, I searched from my desktop for my Android – and it accepted it! 8) I was then able to push a simple text file down onto the smartphone without issue; it stored the file in the “Bluetooth” folder off the \Root. I then reversed the process and “sent” the file back (req’d that I tell BT on the desktop to receive a file, else it fails at the phone) which deposited in My Documents. Righteous! Needless to say this is a major coup, and one big-o feature that I no longer need to write for the proposed Mobile application.

For those that want to bind their non-Windows Phones to Windows 7 x64, Google search for: “Bluetooth_Broadcom_6.2.1.1200_W7x64_A.zip”. This package also carries the drivers for Vista x64, and the x86 for Vista/Win7. Unzip the file and use the manual process to update BT in Device Manager by pointing to the unzipped directory and just let the wizard search from there.

Another alternative is to "Download updated Bluetooth® for Windows® software" directly from Broadcom. This wizard did not work for me. To be honest, my hardware came from Logitech (w/ 19-in-1 built-in I/O adapters) and integrated into my Dell machine at the factory. I think my problem was that the OEM Hardware driver was overwritten which disabled BT hardware visibility - even though the BT Service could still run. Your systems will be different.

Right. So now that my BT is working (and can see my smartphone ) I just need to solve serial over BT which is a lot easier to do than moving files.

Onward through the snowy drizzle, KF

 

[bigmoose]

I'll sure encourage you! Because I think it would be phenominal to have the ability to write Android aps to interface with microcontroller projects!

I'll also buy you a Friday night pint! Just let us know how to do it.

 

[whereswally606]

If you are ever in Manchester, England ill buy you a guiness KF. good work on this, keep it coming.

 

[Kingfish]

Thank ye fine gentlemen for the kindred virtual beers! And I have very fond memories of enjoying the Cream of Manchester in Manchester at a pub off a busy 2-lane road where my future Ex sang to me in front of a 14-piece jazz band “The Girl from Ipanema” – man did she have a voice! It’s one of my very favorite moments from Life! Though I am very sad that Bodies is not brewed there anymore, a Guinness will work just as well

~I am honored!


Status for Friday, March 22 – EoW

• Created cable adapters for the BT module for connection to PC and to the Controller. Using old 4-pin controller connections, I crafted two Females and one Male connector.
  • One Female attached to a USB cable to power the BT device and mate it with both Android and Desktop. The BT module that I own shows up as “linvor”, having a pass key of “1234”, and provides BT Serial Services.
  • The other Female connector attached to the Male connector as an adapter between the BT module and the Controller Programming adapter. Swapped RXD and TXD positions to get the pointouts correct between the devices.
  
  
  Here's the lot L to R: Adapted USB to BT Female so we could power & pair the device, BT Module with mini-adapter cable, Programming Adapter Cable.
  ...
• Ran a bit of .NET code that searches for BT devices and it found both the Android and the BT Module. The application has a search & find feature, and that was tested over several distances with positive results. The code though uses a proprietary assembly that may require licensing. I am looking into alternatives, although it’s nice to know the entire codebase was written in CSharp using Windows Forms which is exactly the format we’ll need to port to Mono.
• Tested BT module with Controller. I was curious how we are going to power this BT device, so I connected it to one of my controllers: There is a subminiature Red LED on the board and it flashes when activated. However there was no indication of power when attached to the controller even when that unit was powered up. However – When I depressed the Reset Button on the Programming Cable – the BT Module had power.
  • This begins to make sense, because during normal operation, the USB cable provides power to the Serial device and we use that same power to reset the MCU on the controller when it is unpowered. In fact – I can’t recall having the controller powered when I set my parameters… possibly out of habit. Therefore I must conclude that we will need an external power source to flash the controller.
  • For the BT Module Power Source, I propose we use a 9V battery and run that into a 7805 Voltage Regulator to get 5V out. It’s small, compact, almost the same size as the board, unless someone wanted to string 4 AAA cells together; I think the 7805 will still work in that mode down below 5V, and I think the specs for the BT Module are good to 3.3V… but don’t quote me. Anyway – that’s my solution to powering the BT Module in the field.
  
  
  Thinking out loud, attach Battery_Negative to Black wire and VR_Out to Red wire; might be prudent to have an On/Off switch too.
  ...
• Created a new topic in the Polls & Surveys section called Controller Model # & Program: We’re looking to see if members have other controller models of the EB-series, and if they use other programming applications with the goal of importing those profiles and flash them correctly. Please take a moment to review the Survey and provide input if applicable.

I think we’re making good progress here in Redmond. I have .NET code that can find the devices, and I am confident we can stream to them shorty. The burning question is whether we can deploy this as shareware without having to worry about licenses. On that front – I am looking for Open Source alternatives.

In addition, I am not convinced that particular working library is directly portable to Mono – hence why I am looking for a pure CSharp solution. I know Android has their libraries – but those are written in Java. Going to Mobile devices is a hurtle – I just don’t know high the bar will be just yet.

Though today, and for the week – I’m pretty happy.
Thanks for your support. KF

 

[Kingfish]

Android Required Reading:

android-serialport-api (must read... really - you must)
This is a fickle pie to hold and comprehend. Arduino solved the problem by using their XBee Shield and ADK; I'm not quite there just yet.

Also - an advancement for PCs:
I realized earlier this late afternoon that pairing the BT module to the PC opened Serial services; reading between the lines... it creates COM Ports! I saw it occur in the Device Manager on Win7 (my Dev platform), and I checked this using a couple of other apps including XPD - which sees these as extra COM Ports. Therefore:

• I believe it is possible to flash a controller from the PC wirelessly using a paired BT Serial Module by virtue of exposing Serial Services. This is an untested theorem because I have not yet configured the BT Module with external power. Although... one of smoke detectors failed in my abode and was replaced some weeks ago, so I have a 9V battery + connector, and I think I can salvage a 7805 VR from one of my other prototypes to make a go of it by tomorrow. However, if some intrepid ES denizen should beat me to the punch and confirm - that would be time saved :wink:

Time for din din. KF

 

[Kingfish]

Status:
Good news: I found another EB212 controller that I could flash. It has a blown FET(s) so no-joy on getting that end of the bargain to run – although it will flash and that’s good enough for testing applications.

• This morning I built a 9V-to-5V power supply using a L78L05A Voltage Regulator that I repurposed from another project. The spec sheet says it puts out about 100mA. Hooked up the BT Module and there was enough current to power the device. However this exposed problems in the next step…
• Flashing failed: The tried & trusted XPD application became lost using the BT-provided COM Port, and I was unable to lurk on the BT transmission to view the dialog. Probable Issues: Because of my frugality ...and perhaps naivety, the BT module that I purchased appears to have several issues which will ultimately block further development:
  • No spec sheet.
  • Inferior BT Version (V1.1)
  • Inability to access & reset the Baud Rate without another device
  • In addition I believe the module draws 50 mA just for BT radio, plus there are other current needs onboard, plus we still need some current to flash the MCU. The L78L05A is limited to 100mA, so perhaps we need to upgrade to 250mA range; L4931 or MCP1702 look like good candidates.

Reviewing what I know to date:

• Android does not support Uart (e.g. access to Serial protocol) below Android V3.0; that’s pretty much every phone more than a year old – and I’m not going out to buy another phone.
• It has slowly become clear that the proper way to program a controller is through a COM Port. That seems obvious for the PC because they are built-in, although for Android – this presents a real problem for us.
• A solution that is becoming more and more obvious is to use something like the Arduino Bee, and it’s either one to two purchases to create the device:
  • FTDI UartSBee V4 XBee/BTBee Bluetooth USB to Serial Adapter
    Bluetooth Bee: Bluetooth to serial port module
  Together they create a Uart Serial COM Port with Bluetooth & USB connectivity for about $25. Given that – it might be possible to mate the existing Silicon Labs USB-TTL Adapter to the BT module in my possession and try to use the USB Port to reset the baud rate via AT commands, although I’m not entire sure that will work; checking: I tried sending AT and ATX to it but it just sits there; it might be too stupid to allow AT commands.

Continuing…

• Without the COM Port – we cannot set the Baud rate for the EB2 and EB3 series controllers. We cannot setup proper handshaking or get error codes or acknowledgment of our existence; the COM Port is crucial, and Android won’t give us one or let us talk with theirs.
• The workaround is to create an application that talks directly to the hardware (like we can do in Windows) and pass our data through the COM Port – whether it is located onboard or remote – and transfer our settings to the MCU.

Now I think I know enough to reply to johnamon:

I worry that the software porting and bluetooth implementation will be so difficult that the project will get bogged down due to being 'too difficult'

To clarify my idea - I would not attempt to port software to the arduino, rather write a simple menu system that contains the 20 or so variables to be set - and construct the serial string manually - this will be very very easy and easy for others to repeat.

Screen and button for menu navigation can be achieved with something like this

Anyway, it would be very very cool if you get this working, however you do it 8)

One of the features I have toyed with for the application that I am developing is to save/store the controller configuration in HEX instead of ASV: Of the latter, that particular file format has both string and numeric values separated by linefeeds; it’s old school – and it required two additional calculations on each and every parameter to be useful: One for the User Interface to present it in friendly terms, and the other which turns it into bytecode for flashing.

If we just store the values in HEX, it’s one conversion to go to ASCII-BIN for flash; no calculation. The challenge is reversing the Hex values into friendly UI human readable values. So in this manner we could export flash-ready data to an Arduino device. But there’s another belly-rub we have to perform on the alligator before he will consume it, and this is the downside of an otherwise good plan:

• Each controller family does a slightly different communication dance with the MCU: Baud Rate, ping value, acknowledgement, ready-to-receive, receive-acknowledgement… they are different for EB2XX, EB3XX, and EB8XX. We’d have to break that part of the program out and code it up for Arduino.
  
  I really only want to write code once. I think it will be a challenge to keep that goal between Desktop, Android, iPhone, and tablets.

But I am coming around to the conclusion that we need better hardware to mate with the controller for a better wireless experience. On that note:
Have I missed something? Is the Arduino XBee BT USB thing the most up-to-date technology? Arduino website plays it down as archaic technology… and I have no experience working with it… yet

But that’s where I’m at: Looking at making a better quality purchase. I think it will simplify the Android development because there are other folks doing the same, and sample code is out there.

Whatcha think? KF

 

[johnamon]

One of the features I have toyed with for the application that I am developing is to save/store the controller configuration in HEX instead of ASV: Of the latter, that particular file format has both string and numeric values separated by linefeeds; it’s old school – and it required two additional calculations on each and every parameter to be useful: One for the User Interface to present it in friendly terms, and the other which turns it into bytecode for flashing.

If we just store the values in HEX, it’s one conversion to go to ASCII-BIN for flash; no calculation. The challenge is reversing the Hex values into friendly UI human readable values. So in this manner we could export flash-ready data to an Arduino device. But there’s another belly-rub we have to perform on the alligator before he will consume it, and this is the downside of an otherwise good plan:

• Each controller family does a slightly different communication dance with the MCU: Baud Rate, ping value, acknowledgement, ready-to-receive, receive-acknowledgement… they are different for EB2XX, EB3XX, and EB8XX. We’d have to break that part of the program out and code it up for Arduino.
  
  I really only want to write code once. I think it will be a challenge to keep that goal between Desktop, Android, iPhone, and tablets.

But I am coming around to the conclusion that we need better hardware to mate with the controller for a better wireless experience. On that note:
Have I missed something? Is the Arduino XBee BT USB thing the most up-to-date technology? Arduino website plays it down as archaic technology… and I have no experience working with it… yet

But that’s where I’m at: Looking at making a better quality purchase. I think it will simplify the Android development because there are other folks doing the same, and sample code is out there.

Whatcha think? KF

There's a lot of information in there! :? It appears that there is at least one issue which you have described above which is solved now and can now be closed out? How you store the variables is neither here nor there really because you seem to have developed a couple of ways to present values to the user, and present them to the controller - so I'd say that's no longer a problem - although it may be a pain to program, put that to one side now move on to the bigger problem.

Hardware.... You still seem sure that you want to develop an android app - I'm not sure that's the best way forward, many people don't own and android device. I don't diss android at all - it's just that you are eliminating many (me included) from your user base.

You could do something like this to relay commands from your phone to the arduino for onpass to the controller.

An arduino nano can be powered from the throttle 5V supply and duck taped or whatever to the side of your controller (they can be had super cheap from Chinese ebay vendors). Given that you are bluetoothing via android, you only need enough pins for 2 SoftwareSerial connections, and can in theory use one of my favourite ATtiny's - although that may not work as you need a means of resetting the MCU which may require an additional arduino pin / transistor to replace the reset switch on lyen's programming cables....

 

[Kingfish]

Proposed Configuration Save formats:
This is a feature that allows you to export the controller configuration into legacy ASV; there’s at least 3 flavors that I know of. But – is it worth it to export to ASV? That’s why I posted the survey. My favorite ASV format is the one used for XPD (not that I’m biased, but it is the most modern). The native format for the new application will be in HEX or ASCII-BIN or XML or JSON; I haven't fully decided, although HEX is pretty easy. But this is cart before the horse. We still have to achieve the primary goal – and that’s flashing via BT.

“You could do something like this to relay commands from your phone to the arduino for onpass to the controller.”

Read that a couple-three times. It misses the salient point which is you still need to present a COM Port so we can instantiate a Serial device, configure it so it can talk to the MCU, than then present the bytes. The hardware is interest though. BTW -that setup is using the ADK; I have that d/l’d already – it’s all Arduino-based API. But we still need a configurable COM Port: Without a COM Port (or SoftSerial) we are going nowhere. Reading the SoftSerial Example code: Looks promising! But keep in mind that the MCU requires handshaking. If we stick with hardware that’s understood – we can cut to the chase… with gravy!

“Hardware.... You still seem sure that you want to develop an android app - I'm not sure that's the best way forward, many people don't own and android device. I don't diss android at all - it's just that you are eliminating many (me included) from your user base.”

The goal is to have an application that works on portable devices. The most popular portable device is an Android, followed by iPhone. If I can write the code in CSharp and get it to work, then I can port that code over to Mono or Java. I’d rather not do any porting but it is unavoidable, so I’m picking Mono (at this time).

Can you spell out exactly what portable device you have?

~KF

 

[johnamon]

I have an iPhone.

SoftwareSerial should work for talking to the MCU.

I don't quite follow the com port issue unfortunately, I've read the post a couple of times but I just don't have the depth of knowledge you do - please don't spend your time trying to explain the com port issue in detail, going round in circles is not going to pogress the build! :lol:

Without fully understanding all the issues above, this is how I see it:

• The indestructable I linked to showed how somone sent data from a phone to a arduino - that's exactly what you want to do. I doesn't really matter whether the data is sent as string, hex, bin or cantonese - because you can program the receiving ardiuno to re-encode the data into a MCU compatible format.

• SoftwareSerial will talk to the MCU, and a custom function (send an 8 until a U is received) will allow handshaking etc to be dealt with

• I still don't know how you will reset the MCU - but you can easily use an arduino pin to fire 5V at the MCU or ground a 5V pin

I don't understand bluetooth communications at all, so I realise that I may be glossing over some important issues - but I do understand Arduino fairly well - and it looks like the indestructable link does exactly what you'd like it to - interface your phone to a serial device via bluetooth.

 

[bigmoose]

John I think your links were extremely helpful! It is going to take me a while to digest also, as bluetooth is new to me. But your links added a fair bit of information that we were missing as the bluetooth boards came with no data sheet or manual.

Thanks for those links!

 

[Kingfish]

Gents -

Here's some of the data I looked at yesterday:
Wireless Serial 4 Pin Bluetooth RF Transceiver Module Backplane RS232
The specs on this board pretty much convinced me that the board I purchased (which had zero information) was inadequate because it will not respond to AT commands sent. Caveat emptor.

Serial Bluetooth Telemetry
These guys put together a really nice way to program a BT RF Transceiver for Copter Control - but you still need another board (or COM Port) to do it.

Cut to the chase with and all-in-one solution:
Arduino BTBee/Bluetooth Bee USB Adapter (or shield) + one of these in an HC-05 or -06 flavor and we're back to $25-27 USD.

I have to say after looking at these little multifunction boards that they are smart little purpose project; a person could do up a nicely programmable augmented, articulated, & aware robot to suit. Fun distraction for a Sunday... :wink:

I want to review the MCU specs though to be sure I haven't missed something else. An awful lot is resting on the COM Port, and I'm not entirely convinced yet that we can change the programming on the fly via BT from Android.

Sad news: My little USB to TTL board died yesterday. It gave up the ghost and is unresponsive... so now I can't flash dirt. Means I need to replace both units. The All-in-one solution is looking very attractive. Unless my comprehension shifts dramatically, that's likely the pool I'll plunge into next.

johnamon, glad you are using an iPhone; that's within the target platform goal of Desktop, Tablet, Mobile (Android & iPhone).
Leaving no stone unturned, KF
EDIT: Fixed bad link

 

[nieles]

The specs on this board pretty much convinced me that the board I purchased (which had zero information) was inadequate because it will not respond to AT commands sent. Caveat emptor.

did you put a 3.3v signal on the "key" pin on start-up to get in to the AT command mode?

 

[Kingfish]

No - I don't have 3.3V available except from the USB-TTL board - and I didn't get a chance to mate them... although about going in that direction until it died. However this brings up one of the points I was trying to make earlier in that we should be able to configure this solution through software:

I don't want to have to go through some mechanical process to change the modem speeds if I am flashing to an EB2xx, and then an EB3xx. I don't need to do this with normal COM Ports and I don't want to do it with BT. :|

I'm trying to keep the kluge factor, as well as the costs to a minimum. It needs to be brain-dead simple: Load the application without a big hassle, plug it together, select your customized controller profile, then launch the flash process, hit the reset button on the hardware - success! Then go ride 8)

Trying to keep it simple for the user... KF

 

[bigmoose]

KF, this link posted two above is bad. Any chance of a revision?

Here's some of the data I looked at yesterday:
Wireless Serial 4 Pin Bluetooth RF Transceiver Module Backplane RS232

 

[Kingfish]

BigMoose - thanks for the heads-up on the link; I've fixed that now. However I have even better info below... :wink:

Bluetooth Serial Port Module for Arduino

Posting this information for edification. I ran across some very deep specs on this device, that may be applicable to my board.

Looking for an easy way to wirelessly communicate with your Arduino microcontroller? This Bluetooth module is an inexpensive way to let your Arduino exchange data with an Android Phone, iPhone, or PC with a Bluetooth radio. This module works much like a PC modem, it is controlled using "AT" style commands and is easy to get running. This is a very popular board and many tutorials can be found online for using this Bluetooth module with your Arduino.

The full documentation for this module can be downloaded here
(KF says: This is a 23-page spec with pinouts, schematic, AT commands, and more! 8) )

As you can see from reading CuteDigi's documentation, this module's capabilities are vast, and there are a great many AT commands for configuring all the minutiae of the bluetooth protocol. This is daunting for the hobbyist who wants a drop-in replacement for a wire, without any additional conceptual sophistication.

Fortunately, such simplicity is provided in this module's default configuration. This module has only four external pins: ground, power, transmitted data, and received data. The default UART parameters are 9600 bits per second, 8-bit word-length, 1 stop bit, and no parity bit. This combination of parameters is commonly abbreviated as 96008N1. The default bluetooth device name is linvor. This is the name that will show up on your PC or smartphone when you attempt to discover nearby bluetooth devices while this module is powered up and in range. The pairing code is 1234. You will need to enter this code on the host bluetooth device during the bluetooth pairing process.

After the pairing process, this device will show up as a serial port on your PC; for all intents and purposes, you can pretend that the module's transmit and receive pins are connected by wire to a physical serial port on your PC. This functionality will satisfy the recreational user.

However, if you want more control, you will be pleased to learn that, in addition to the four external pins mentioned above, there are two through-hole solder pads which provide extended access to the device. These solder pads are in line with the other four pins, and would readily receive two additional header pins. The names printed on the board next to these two solder pads are STATE (with an arrow indicating that this pin is for data coming out of the module) and KEY (with an arrow indicating that this pin is for data going into the module). The STATE pin provides access to the signal that drives the onboard status LED. The KEY pin is connected to the PIO11 pin of the CuteDigi module. Driving the KEY pin high puts the module into AT command mode, wherein you can set and retrieve all sorts of settings by sending and receiving AT style modem commands through the Tx and Rx pins. The AT commands allow you to change the bit rate, set the device name and address, turn the device into a bluetooth master, configure pairing with other devices, activate and configure power saving mode, and enable encryption - just to name a few.

For usability and price, this board is hard to beat.

This module has a 4 pin 0.1" spaced header, and includes a 4 pin connector and 4 single pin connectors on a 6" cable.

They have this board in stock. Why am I looking at this again? Because I cannot find the two XBee boards previously mentioned in this country (unless you want to pay double or triple the price), and I don't want to wait 15-29 days for the slow boat to arrive.

If I can trick my BT module into accepting AT commands, welllll - that's a good start. I don't know yet if it will stay in that mode or reset on power-cycling. According to the spec, if "PIO11 is set to high" followed by power-On, "the module will enter into AT command mode". So does that mean we always want the pin high to control the board? Reading on, there are 3 modes: Slave, Master, Slave-Loop. Some ports can be programmed high or low, but not PIO11.

Attempting to program: Looking at this board, I know now why I got a deal on it... one of the SMD LEDs is missing. Pin 34 (PIO11) wasn't soldered. Did that - but still no joy; cannot send AT commands to the device. I do have a modem currently connected that I use for logging Caller ID; it uses Tera Term as the interface... I can definitely send AT commands to it. Not sure what is wrong with the BT module, but I am also aware it could be operator error.

Wireless Network Adapter:
Looked briefly into this because my phone can link to other wireless devices aside form BT. However that technology appears even more expensive than BT.

That's what I know for the moment. Driving myself batty with this AT command stuff. :?
~KF