Home Page | Forum | Downloads | About us | Services | Products | Online Portal | Site Map | Contact Us

motorola
November 22, 2019, 07:54:58 PM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News:
 
   Home   Help Contact Admin Team Search Login Register  

Radio Services

Supply Radios, Spare Parts, Programming Cables, Flash Adapters

Members area provides radio programming videos

If we have helped you, please make a donation, however small. This helps us develop the site and offer better services.

Advert

Pages: [1] 2 3 ... 10
 1 
 on: October 29, 2019, 12:31:33 PM 
Started by Sputnik 1 - Last post by Andreas GH
Install the proper firmware and go to recover radio.

 2 
 on: October 28, 2019, 09:35:09 PM 
Started by onmia - Last post by Snopeak
Could I request the same, have CPS 16, build 823

 3 
 on: October 28, 2019, 09:25:55 PM 
Started by Sputnik 1 - Last post by Snopeak
Thanks for the responses, using using CPS 16.0 (Build 823).
 

 4 
 on: October 28, 2019, 05:23:30 PM 
Started by xjapanseikima - Last post by xjapanseikima
You are very welcome, and I'm glad I was able to help.

 5 
 on: October 28, 2019, 04:54:40 PM 
Started by xjapanseikima - Last post by mmjc23
Hi Alex,

Thank you so much for your answers and your time.
I did some tests and I think I understood...

It is not necessary to decode and reply to every XCMP message but IT IS MANDATORY to decode and reply to ALL XNL packets.
I try to explain...
When an application establishes an XCMP/XNL connection with a MotoTRBO radio, the radio expects to receive a REPLY for each REQUEST that is forwarded to the application (XNL Protocol).
The XCMP message is contained within the XNL payload package...and I don't have to decode and reply to all XCMP messages.
If (for example) I am interested in viewing only the calls in my application I can decode only "CALLCTRLBRDCST" XCMP messages (OPCODE: 0xB413)...I am not obliged to interpret other XCMP messages ("DISPTEXT", "INPUTDAT", etc.)!

What have I done now?
To simplify and speed up the development of my application, I decided to use only the C# XNL project of the "XcmpXnlSampleApp" example program provided by Motorola.
The Motorola C# XNL project, seems not to be buggy...so, I already have all the low level protocol management (XNL) ready-made; and I just have to decode the XCMP messages I want to display in my application (Calls, LogIn, LogOff, etc.)

I started decoding calls
(example of individual call between radio 100 and the radio 101):
28/10/2019 14:58:25 - CallType: EnhancedPrivateCall - Stato: CallEnded - Remote Address: 100 - Priority: 0 (Call ended)
28/10/2019 14:58:21 - CallType: EnhancedPrivateCall - CallStatus: CallInHangtime - Remote Address: 100 - Priority: 0 (PttOff 100)
28/10/2019 14:58:19 - CallType: EnhancedPrivateCall - CallStatus: CallInProgress - Remote Address: 100 - Priority: 0 (PttOn 100)
28/10/2019 14:58:17 - CallType: EnhancedPrivateCall - CallStatus: CallInHangtime - Remote Address: 101 - Priority: 0 (PttOff 101)
28/10/2019 14:58:14 - CallType: EnhancedPrivateCall - CallStatus: CallDecodedClear - Remote Address: 101 - Priority: 0
28/10/2019 14:58:14 - CallType: EnhancedPrivateCall - CallStatus: CallInProgress - Remote Address: 101 - Priority: 0 (PttOn 101)
28/10/2019 14:58:13 - CallType: EnhancedPrivateCall - CallStatus: CallInHangtime - Remote Address: 101 - Priority: 0 (PttOff 101)
28/10/2019 14:58:10 - CallType: EnhancedPrivateCall - CallStatus: CallDecodedClear - Remote Address: 101 - Priority: 0
28/10/2019 14:58:10 - CallType: EnhancedPrivateCall - CallStatus: CallInProgress - Remote Address: 101 - Priority: 0 (PttOn 101)
28/10/2019 14:58:10 - CallType: EnhancedPrivateCall - CallStatus: CallDecoded - Remote Address: 101 - Priority: 0 (Individual Call to 101)


Thank you Alex
Best Regards

 6 
 on: October 28, 2019, 12:13:58 PM 
Started by Sputnik 1 - Last post by Andreas GH
You should try it with CPS 16 and the proper firmware.

 7 
 on: October 27, 2019, 12:22:33 PM 
Started by Sputnik 1 - Last post by emsgeorge
Because that post is several versions of cps ago... and 5 years.

 8 
 on: October 22, 2019, 09:45:55 PM 
Started by Rob - Last post by Snopeak
Is this forum stiull used?

 9 
 on: October 22, 2019, 08:50:22 PM 
Started by Sputnik 1 - Last post by Snopeak
I have tried following the above but received tghis message - No matching package (s) exist

Any advice?

 10 
 on: October 12, 2019, 12:15:57 AM 
Started by xjapanseikima - Last post by xjapanseikima
hi mmj23,
you are very welcome,
unfortunately, the answer is yes, you should reply the each message which sent from the motorola radio.

The reason is, in the reality, your radio will keep sending the XCMP message to your application.
For example, if you press the "PTT" button, the motorola radio will send the command to ur application.
So,at this moment, your application will be interrupted by the command, then you need to send back an ACK to confirm it.
(For each command, they need an ack. Except the ack).
If you didn't send back ack, the radio will stop at this moment until it get ack. So, during this time, you can't send any command.

Or!!! if your don't mind you need to reconnect your application again.. and you can guarantee there won't be any other radio influence your radio
then yea, you don't need to send back ack... (but it's really hard to have this thing happened in the reality)
 
In fact, you don't need to decode the complete message. You just need to decode some part of the message,
So, the below process is how I deal with each message once I get from the radio,
for each message:
  /*decode this message into an array or whatever data structured you like*/
  /*take a look at "MOTOTRBOTM XCMP/XNL Development Guide" of the  data structure.*/

    message=Decode( OPcode); // you don't need to decode it completely, but the comment below is the important parameter for sending back ack
   // message[0] , message[1] mentions the length of this command
   // message[2] , message[3] this is OPCODE,  X000B is command, X000C is ACK
   // message[5]   flag
   //message[10],message[11]// Trancation ID
          if(OPCODE== 0x0B) // you just need to take care of X000B
         
              byte ack[] = { (byte) 0x00, (byte) 0x0C, (byte) 0X00, (byte) 0X00C, (byte) 0X01, // Protocol ID
            (byte) message[5], // FLag
            (byte) RadioAddress[0], (byte) RadioAddress[1], (byte) MasterAddress[0], (byte) MasterAddress[1], //
            (byte) message[10], (byte) message[11], // Transaction ID
            (byte) 0X00, (byte) 0X00// payloadLeng
      };
              sending back ack;
if you need it, I can send the "XCMP-Based IP Capable Peripheral ADK Development Guide" to you.
or I can send you the screen shot for my radio decode part, it's not that hard,
(I already upload all my code to github)
A quick question,
Did your application connect to the radio? That's  the fundamental part of this application

Pages: [1] 2 3 ... 10
Home    Forum | Downloads | About us | Services  | Products | Online Portal | Site Map | Contact Us

Copyright 2008-2010 Motorola Radio Support Group. All Rights Reserved.

Google PageRank
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Sitemap Valid XHTML 1.0! Valid CSS!
Page created in 0.053 seconds with 19 queries.

Google visited last this page October 09, 2019, 01:29:30 PM