Communications Support Forums
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.trbotools.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
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.trbotools.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