API availablility

axa88 · Feb 9, 2022

So in my recent thread I asked for the case for TouchDRO vs economy DROs, well seems i didnt need much convincing and bought in.

Now I have a few questions of my new hardware...

- Is there an API for the interface, ie any technical description how the hardware puts out coordinates so it could feasibly be interfaced via Bluetooth with another custom device than one running TouchDRO app. Pairing inst application locked is it?

- if an API is available is it possible for the adapter to pair and communicate with more than one interface?
I would imagine that serial bluetooth classic is being used, but i am unaware of the details having no experience.
But for example a BLE connection can maintain multiple connections between peripheral and central.

- from the product specification page there is mention of "SPI input." Any specification on its usage?

sdavilla · Feb 9, 2022

It's real easy to talk to the TouchDRO controller. I've done it under macOS using both the system emulated serial device and direct bluetooth API.

Pairing does not keep other devices from connecting. But based on what I've seen, he who connects last, gets it and the other device is kicked off.

It would be nice to know the exact formats that could be output from the TOuchDRO controller, max string sizes and such.

ycroosh · Feb 9, 2022

The protocol is described here: https://www.yuriystoys.com/2012/09/android-dro-communication-layer.html. It's simple ASCII format that sends axis position as "x-12345;". Basically axis label followed by optional minus sign, then up to 10 digits and terminated with a semi colon.
Some adapters output a bit of extra garbage that I was going to use in the app to do some automatic configuration (like "v0120;" which is a version designator, but that's not used or relevant.

Right now the adapter can't communicate with multiple devices. It can be paired with 4 or 10 (I don't recall how many I chose in the firmware), but only one can be connected. I am planning to add BLE, but that is probably a 2023 thing.

SPI input is for future expansion. I have a pipe dream of adding some two-way capabilities, like a way to drive a lead screw or stop the feed at certain position. The pins are connected, but nothing is implemented in the firmware yet.

sdavilla · Feb 9, 2022

Ohh, with BLE that raises the possibility of iOS devices without having to resort to private libs. I'll be a g-pig for that please...

ycroosh · Feb 9, 2022

sdavilla said:
Ohh, with BLE that raises the possibility of iOS devices without having to resort to private libs. I'll be a g-pig for that please...

So, "it is our corporate policy not to discuss future product enhancements and timelines"

but... once the new app version is out, I will be updating the adapter firmware to add BLE and a few other small tweaks. My goal, funny enough, is to enable the app to be connected to multiple adapters, which is easier with BLE than standard RCOMM. I'll ping you when I have a beta version ready.
For parsing, this is my code:

/**
* @param value
* @return Returns true if the input is accepted; false otherwise.
*/
@Override
public boolean accept(char value) {

    switch (state) {
        case Axis_Label: {
            InputAxis inputAxis = ParseAxis(value);


            if(inputAxis== InputAxis.P){
                this.inputAxis = inputAxis;
                state = ParserState.BooleanDigit;
            }
            else if (inputAxis != InputAxis.NONE) {
                this.inputAxis = inputAxis;
                state = ParserState.DigitOrSign;
            }

            break;
        }
        case DigitOrSign: {
            //first thing after the axis can be a sign or a digit


            if (value == '-') {
                multiplier = -1;
                state = ParserState.Digit0;
            }

            if (Character.isDigit(value)) {
                position = value - '0';
                state = ParserState.Digit1;
            }

            break;
        }
        case Digit0: {
            //this has to be a digit
            if (Character.isDigit(value)) {
                position = value - '0';
                state = ParserState.Digit1;
            }

            break;
        }
        case Digit1: {
            //this can be a digit or a terminator

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            if (Character.isDigit(value)) {
                position = position * 10 + (value - '0');
                state = ParserState.Digit2;
            }

            break;
        }
        case Digit2: {
            //this can be a digit or a terminator

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            if (Character.isDigit(value)) {
                position = position * 10 + (value - '0');
                state = ParserState.Digit3;
            }

            break;
        }
        case Digit3: {
            //this can be a digit or a terminator

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            if (Character.isDigit(value)) {
                position = position * 10 + (value - '0');
                state = ParserState.Digit4;
            }

            break;
        }
        case Digit4: {
            //this can be a digit or a terminator

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            if (Character.isDigit(value)) {
                position = position * 10 + (value - '0');
                state = ParserState.Digit5;
            }

            break;
        }
        case Digit5: {
            //this can be a digit or a terminator
            //this can be a digit or a terminator

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            if (Character.isDigit(value)) {
                position = position * 10 + (value - '0');
                state = ParserState.Digit6;
            }

            break;
        }
        case Digit6: {
            //this can be a digit or a terminator

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            if (Character.isDigit(value)) {
                position = position * 10 + (value - '0');
                state = ParserState.Digit7;
            }

            break;
        }
        case Digit7: {
            //this can be a digit or a terminator

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            if (Character.isDigit(value)) {
                position = position * 10 + (value - '0');
                state = ParserState.Digit8;
            }

            break;
        }
        case Digit8: {
            //this can be a digit or a terminator

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            if (Character.isDigit(value)) {
                position = position * 10 + (value - '0');
                state = ParserState.Digit9;
            }

            break;
        }
        case Digit9: {
            //this can be a digit or a terminator

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            if (Character.isDigit(value)) {
                position = position * 10 + (value - '0');
                state = ParserState.Terminator;
            }

            break;
        }
        case Terminator: {
            //write out the data;

            if (AcceptTerminator(value)) {
                return makeRedatout();
            }

            ResetStateMachine();

            break;
        }
    }

    return false;
}

axa88 · Feb 10, 2022

ycroosh said:
The protocol is described here: https://www.yuriystoys.com/2012/09/android-dro-communication-layer.html. It's simple ASCII format that sends axis position as "x-12345;". Basically axis label followed by optional minus sign, then up to 10 digits and terminated with a semi colon.
Some adapters output a bit of extra garbage that I was going to use in the app to do some automatic configuration (like "v0120;" which is a version designator, but that's not used or relevant.

Right now the adapter can't communicate with multiple devices. It can be paired with 4 or 10 (I don't recall how many I chose in the firmware), but only one can be connected. I am planning to add BLE, but that is probably a 2023 thing.

SPI input is for future expansion. I have a pipe dream of adding some two-way capabilities, like a way to drive a lead screw or stop the feed at certain position. The pins are connected, but nothing is implemented in the firmware yet.

Very interesting to see how you implemented comms. I would have thought you would have needed to compress serialized data using something like bson rather than ASCII, but I guess in practice you proved it unnecessary.
Though if implementing BLE GATT profile for instance I recall being limited to 21 bits per message and needing to convert data to implement some sort of compression. But you do get the advantage of multiple simultaneous connections.

i would propose TouchDRO needs not to have 2 way comm. It's is an excellent coordinator system,so im told

, perhaps it's optimal to put the burden of additional functionality on to new hardware while Touch DRO remains a one way coordinate source.

Though its hard for me to think of any other additional application then that which controls feeds/speeds, but how great would it be if you release an SPI API and people can develop add on components.
But if opening it up, be sure to implement at least 1 active CS line even if the design ends up without any need for chip selection. There are SPI devices that NEED to see the CS transitions between messages regardless.

Exciting stuff. Hope you come back to bounce around ideas.
And thanks for the parsing code. Having source code and detailed specs saves so much work.

ycroosh · Feb 10, 2022

axa88 said:
Very interesting to see how you implemented comms. I would have thought you would have needed to compress serialized data using something like bson rather than ASCII, but I guess in practice you proved it unnecessary.

I did it this way back when the whole thing ran on Arduino. I toyed with the idea of compressing the data, but didn't want to break the API. At this point it's not really that important (BT4.0 can pump a lot of characters fast), but when I was limited to 9600 BAUD between MSP430 and HC-05 it bugged me a lot.

axa88 said:
Though if implementing BLE GATT profile for instance I recall being limited to 21 bits per message and needing to convert data to implement some sort of compression. But you do get the advantage of multiple simultaneous connections.

I need to sit down and really think hard how I want to do BLE.

axa88 said:
i would propose TouchDRO needs not to have 2 way comm. It's is an excellent coordinator system,so im told , perhaps it's optimal to put the burden of additional functionality on to new hardware while Touch DRO remains a one way coordinate source.

Though its hard for me to think of any other additional application that which controls feeds/speeds, how great would it be if you release an SPI API and people can develop add on components.
But if opening it up, be sure to implement at least 1 active CS line even if the design ends up without any need for chip selection. There are SPI devices that NEED to see the CS transitions between messages regardless.

Noted

axa88 said:
Exciting stuff. Hope you come back to bounce around ideas.

I tend to over-bounce ideas, so definitely will do

axa88 said:
And thanks for the parsing code. Having source code and detailed specs saves so much work.

axa88 · Feb 17, 2022

axa88 said:
But if opening it up, be sure to implement at least 1 active CS line even if the design ends up without any need for chip selection. There are SPI devices that NEED to see the CS transitions between messages regardless.

Yuriy is way ahead it seems, just got my hardware and see a CS0 on the silk screen. The future looks bright..

Welcome back Guest! Did you know you can mentor other members here at H-M? If not, please check out our Relaunch of Hobby Machinist Mentoring Program!

API availablility

axa88

Registered

sdavilla

Registered

ycroosh

Active User

sdavilla

Registered

ycroosh

Active User

axa88

Registered

ycroosh

Active User

axa88

Registered