On the drawing board

[Administrator]

Hi guys,

This thread is aimed at experimenters and hackers (in the original sense and not the 'new' sense :wtf:).

For quite some time I've been mulling over an idea proposed by several Ham operators - that is:- allowing remote 3rd party applications to access and control a MotoTrbo radio.

In thinking about this project, several things immediately spring to mind ..
1. Write/code a Server app (initially TransTRBO) that will sit and listen for multiple incoming connections and Commands/Requests (TCP/IP already done).
2. Write/code a remote client (VC++, C, C++, PHP, Pearl, VBS etc.) that will send Requests/Commands to the server (VC++ & PHP already done)

Then we hit the hard part:-
3. Define the type of Requests/Commands/Responses/Data that will be most useful to Ham operators.
4. Define an ANSI Text Based protocol to handle both the requests and responses between the server & client
(this would eliminate any network endian-ness and allow access by more 3rd Party Apps)
5. Allow the client to 'Register' for 'services' that aren't static, i.e. to receive notification of Asynchronous Radio Events from the Server, name it with a unique "userSequenceNumber"
i.e. incoming Calls, ARS updates, GPS updates, incoming radio Text messages etc
6. Add a Parser for #4 and stick it in the server

Open Source for Client Apps and utilities
7. Create common client language "libraries" that are "open Source" (I can do this readily for VC++, C, C++ and PHP)
i.e
8. TCP/IP Client
9. Command generator
10. Result/Data parser
11. eMail handlers
12. SMS handlers
others ..

Open Source for Server-side
I'm happy to share the non-proprietary parts of the Server software
TCP/IP Server (VC++)
Command Parser (VC++)
Response/Data Generator (VC++)
(I'll post my Client/Server Source on http://www.transtrbo.com - if there is any sign of interest from you Ham guys).


This has been stewing around in my brain - especially when I get requests where people would like to do something this ..

Example 3rd Party App
A person wants to send an email message to a specific radio and then receive an email response back from the radio ..
What the 3rd party app would need to do is:-

1. Predefine an email format i.e. Header holds the Destination Radio ID, Body holds the message content
2. Receive a mail message from the net (Save sender information locally), generate a unique "userSequenceNumber"
3. Parse the email message to get the destination Radio ID and the Message content (also validate the format)
4. Register with the server for an interest in "textMessage" and "specificRadioID" (just ideas here see #3, #4 and #5)
5. Command the Server to send a "textMessage" to "radioID" with content "content" (See #3 and #4)
...
6. Receive a delayed/asynchronous message from the server - checking for the "userSequenceNumber"
7. If "userSequenceNumber" matches what is being awaited (client should be able to handle multiple 'pending' responses)..
8. Parse the incoming message and generate the email "body" from it
8. Send the newly built email message back to the Sender

As I said guys, ideas only, but I would appreciate feedback, suggestions etc ..

Now I'm back to work.

cheers
Will B

[no7rf]

This would be a tremendous assest, commercially or ham-related.

I have used the TurboVUi IP Gateway/Sol Client system http://www.ctiproducts.com/turbovui.html and I think it is about the simplest to operate and full control over the control radio remotely. While the company does provide the requisite dispatch services, it's the Solo Client implementation that is of key interest to us hams. Nice touch on the Android App.

So happy to hear that it is on the drawing board or otherwise, rolling around the marble jar.

-- Mike, no7rf@trbo.org

[jjspike]

I would love the ability to send messages and obtain station and location information. I would like to create apps for the community that would allow HAMs to contact or track MotoTRBO users. This would only be the beginning and more complex functions could be developed if an interface was available. Count me in as an interested party.

George
VA3GAM

[Mad4Radio]

I must admit the idea of being able to connect to my mototrbo set via an app on my iPhone would be fantastic, cracking idea

[Administrator]

I must admit the idea of being able to connect to my mototrbo set via an app on my iPhone would be fantastic, cracking idea

Hi Colin,

I am working on the TCP/IP Server at the moment.

This will allow remote locations - LAN/internet connections to Control/Monitor the radio and any of its transactions.
(i.e. your ticketing job - but without having to alter TransTRBO ).

For testing purposes - I'll probably add it to XcmpXnl.exe first.

I am hoping others will write Apps to suit themselves and the TT Server will just act as a Gateway into their radio network.

cheers
Will

[Mad4Radio]

Hi will

Hope all is well, looking forward to the new features in the future then, anything that would allow to connect to the radio from the smartphone via a TCP/IP would certainly get the big huge thumbs up.

Don't work too hard will speak soon

Best & the most kindest regards

Colin

[Administrator]

Hi guys,

I've finally finished a stable TCP/IP Client server package (thanks to some help from http://www.flounder.com ) which I will be adding to the freeware XcmpXnl.exe tool (as the Server).

I will then be writing another App called XcmpXnlRemote which will be based on XcmpXnl.exe, and act as the client(s) for testing.

The VC++ source for the Client and server will be open source (not the XcmpXnl part - sorry).

I'm trying to come up with a good text based protocol that will allow easy/readable access to a Motorola Radio and Network, this is my initial start point ...

Protocol:
The protocol should be all text strings (ANSI + UTF-16) and hopefully the server will be able to detect the endian-ness of remote client.

Hobbyists should be able write their own Apps in their preferred language (PHP, Pearl, VBS, C# etc) and use XcmpXnl.exe as the gateway into their Motorola Radio.

The Protocol I am looking at will require the leading 4 x "text characters" to be the numeric character length of the following text packet.

The client App should be able to Get and Set the radios setting as well as "register" for asynchronous events - such as incoming calls etc ..

The following list is what I'll be working on as a base - suggestions would be appreciated as you guys will be the one using it ...

Set Radio Commands:
Set Zone
Set Channel
Set Volume
...

Get Radio Requests:
Get Zone
Get Channel
Get Volume
Get RSSI
Get Radio ID
Get Product Model Number
Get Product Serial Number
Get Product ESN
Get Signalling Mode
...

Asynchronous Event Registration:
Call Events (Time, Zone, Channel, Call type, Source Radio, Destination Radio/Group)
Channel Change
Zone Change
Volume Change
LCD Display Updates
Indicator changes
...

Administration:
User Logon
User Logoff
...

[Administrator]

Hi guys,

I now have the transport level detecting the data stream type type and it will convert it to the format used internally by the server.
(See bottom of this post ...)

I am now looking at the content of the Data ...
To set the Radio's Zone (channel)

Code: Select all

[4 x char for Length]
[<Command>]

i.e.
To Set Zone to 4
"<SetZone:4>"

Code: Select all

0011<SetZone:4>

or to set Zone + channel
"<SetZone:4,10>"

Code: Select all

0014<SetZone:4,10>

...

To start Monitoring Zone changes from the Radio, 1 => Start ... 0 => Stop
"<MonitorZones:1>"

Code: Select all

0014<MonitorZones:1>

or concatenate 2 x commands

Code: Select all

0030<MonitorZones:1><SetZone:4,10>

Protocol (so far)
For ANSI character set (and packet based Binary Data)

Code: Select all

//	**************************************************************************
//	**                                                                      **
//	**                                                                      **
//	**                                                                      **
//	**      Name:  O n  R e c e i v e  P r o t o c o l  A N S I             **
//	**                                                                      **
//	**      Description:                                                    **
//	**       Receives data of the form                                      **
//	**                                                                      **
//	**       +--+--+--+--+--+--+--+--+--+--...--+                           **
//	**       |    len    |   data               |                           **
//	**       +--+--+--+--+--+--+--+--+--+--...--+                           **
//	**       \__________/ \__________ __________/                           **
//	**                               V                                      **
//	**       4 x ANSI Numeric      len bytes                                **
//	**           Characters                                                 **
//	**    ANSI                                                              **
//	**       The length is a ANSI String containing the integer length      **
//	**          (Network Standard Byte Order is ignored)                    **
//	**       The data is len BYTES long.                                    **
//	**       Allows packets up to 9999 BYTES long.                          **
//	**    BINARY                                                            **
//	**       The length is a Binary integer length                          **
//	**          (Network Standard Byte Order)                               **
//	**       The data is len BYTES long.                                    **
//	**       Allows packets up to 65535 BYTES long.                         **
//	**                                                                      **
//	**      Parameters:                                                     **
//	**                                                                      **
//	**                                                                      **
//	**		Returns:                                                        **
//	**                                                                      **
//	**                                                                      **
//	**                                                                      **
//	**                                                                      **
//	**************************************************************************
void CTcpConnectSocket::OnReceiveProtocolANSI()
{

For UTF-16 (Big Endian and Little Endian formats)

Code: Select all

//	**************************************************************************
//	**                                                                      **
//	**                                                                      **
//	**                                                                      **
//	**      Name:  O n  R e c e i v e  P r o t o c o l  U T F  1 6          **
//	**                                                                      **
//	**      Description:                                                    **
//	**       Receives data of the form                                      **
//	**                                                                      **
//	**       +--+--+--+--+--+--+--+--+--+--+--+--+--+--...--+               **
//	**       |    UTF 16 len         |   data               |               **
//	**       +--+--+--+--+--+--+--+--+--+--+--+--+--+--...--+               **
//	**        \__________ __________/ \__________ __________/               **
//	**                   V                       V                          **
//	**           4 x UTF-16 Numeric         len WCHARS                      **
//	**                Characters                                            **
//	**                                                                      **
//	**       The length is a UTF-16 String containing the integer length    **
//	**          (Network Standard Byte Order is ignored)                    **
//	**       The data is len WCHARS long.                                   **
//	**       Allows packets up to 9999 WCHARS long.                         **
//	**                                                                      **
//	**      Parameters:                                                     **
//	**                                                                      **
//	**                                                                      **
//	**		Returns:                                                        **
//	**                                                                      **
//	**                                                                      **
//	**                                                                      **
//	**                                                                      **
//	**************************************************************************
void CTcpConnectSocket::OnReceiveProtocolUTF16()
{

[Administrator]

This project is moving along and I have now got a "Windows Service" application framework running (thanks to PJ Naughter's source).

I am now adding the TCP/IP server and hopefully soon I'll have the ability to run distributed "Dispatch Consoles".

cheers
Will

[Administrator]

Hi guys,
FWIW this is now being integrated into a LAN version of TransTRBO - as that should fall within our approved Applications of Dispatcher Consoles.

To date: I have a Windows service running that can connect to and control up to 8 x radios concurrently.
The (rudimentary GUI) text based TCP/IP Client implementation allows Binary, ANSI, Unicode (Little Endian) and Unicode (Big Endian) commands/responses and this appears to be working reliably.
So far the commands implemented are :-

• Connect to radio(n)* where n = 0 - 7)
• Disconnect from radio(n)
• Increment Zone on radio(n)
• Decrement Zone(n)
• Increment Channel on radio(n)
• Decrement Channel(n)
• Set Zone (x) on radio (n)
• Set Channel (x) on Radio (n)

It may not look like much atm but it is probably 60~70% complete.

Once the commands are complete - I just have to dispatch each radio's updates to the clients that "Registered" to receive them.
Then a quick peek at Txing Audio across the network ...

The next step will be to build a Dispatch console and then a Remote Radio Head.

cheers
Will B

ServiceClient.PNG (34.17 KiB) Viewed 12477 times