We use MDC call alert to ring down paramedics. We’ve asked Motorola to quote or provide us with an SP or some way of reducing the number of times the signaling BIM tries before giving up (we've been trying for over two years to get this). Our system is so robust we only want to try one time and then go on to the next unit. Not the five times that the signaling modem wants to. Our system performance would be greatly enhanced if we could do this.
At this point we’re attempting to disassemble the resident software and have been successful in getting a hex dump. We have the 68HC11 documentation but that’s all.
I am hoping that someone out there may have already done something like this or could help with any additional information.
Thanks in advance.
Signalling BIM
Moderator: Queue Moderator
I think you are pretty much going to be on your own on this one!
You must be very serious if you are planning to dis-assemble object code into a psuedo-source listing and then try to make enough sense out of it to modify it!
That's probably more advanced than I would tackle, but if I had to - the first thing I would do is try to understand exactly how the system works [perhaps you have already done this] Centracom Series II is a distributed processor system. Each CPU performs specific operations.
Consider a basic page - like a two-tone sequential. When the dispatcher selects this function at the operator position, the operator interface sends a packet to the correct BIM. This packet contains a task code and data. Together, these define the operation, i.e. send a page using such & so format and tones. The BIM then goes off and completes that task, then responds back to the operator that the operation is complete.
The information needed to complete the page is embeded into the BIM firmware. This includes the tone timing and tone encoding data. If custom tone timing or tone frequencies are required, Motorola generates a custom BIM firmware PROM. So how does MDC signalling work?
A signalling BIM combines a regular BIM and an MDC channel modem card. The MDC modem has its own microprocessor and firmware. The big question is - how much of the process does the operator card hand off to the BIM and how much does the BIM hand off to the modem? In other words, which MPU has responsibility for the retries? Does the modem firmware decide to retry or does the BIM or does the operator interface?
There is one parameter the Centracom CDM programming software allows us to set - the wait between retries. That suggests that the entire retry process may be under control of the COIM - in which case nothing could be done to the BIM or modem firmware to resolve your issue.
The one thing you might try to do is decipher the communication between the cards in order to understand the process. The BIM is tied to the modem through a serial interface. You could put a protocol analyzer in that line and see if you can document what happens as MDC call alerts are sent, acknowledged, not acknowledged etc. In other words, it is possible that the BIM sends the page command to the modem and no further communication takes place until the operation is completed - successful or not - in which case the modem firmware would be responsible for the retries.
On the other hand, you might see the BIM ask the modem to send the MDC signal each time the over the air signal is transmitted. In that case - one of the higher level processors would be doing the retries - either the BIM or the COIM.
If you can decipher the comm line between the BIM and the modem, perhaps you will learn something about MDC signalling that you could share here. When you send an MDC call alert from the console, the MDC modem transmits a dual MDC packet [276 ms.] Assuming that your console ID is 0001 [the default] and your target radio ID was 1234, the raw MDC data would be: 3589 1234 830D 0001. See if you can identify the data in the communication beween the BIM and the modem. Presumeably, the link format would also contain command codes, checksums, etc.
You must be very serious if you are planning to dis-assemble object code into a psuedo-source listing and then try to make enough sense out of it to modify it!
That's probably more advanced than I would tackle, but if I had to - the first thing I would do is try to understand exactly how the system works [perhaps you have already done this] Centracom Series II is a distributed processor system. Each CPU performs specific operations.
Consider a basic page - like a two-tone sequential. When the dispatcher selects this function at the operator position, the operator interface sends a packet to the correct BIM. This packet contains a task code and data. Together, these define the operation, i.e. send a page using such & so format and tones. The BIM then goes off and completes that task, then responds back to the operator that the operation is complete.
The information needed to complete the page is embeded into the BIM firmware. This includes the tone timing and tone encoding data. If custom tone timing or tone frequencies are required, Motorola generates a custom BIM firmware PROM. So how does MDC signalling work?
A signalling BIM combines a regular BIM and an MDC channel modem card. The MDC modem has its own microprocessor and firmware. The big question is - how much of the process does the operator card hand off to the BIM and how much does the BIM hand off to the modem? In other words, which MPU has responsibility for the retries? Does the modem firmware decide to retry or does the BIM or does the operator interface?
There is one parameter the Centracom CDM programming software allows us to set - the wait between retries. That suggests that the entire retry process may be under control of the COIM - in which case nothing could be done to the BIM or modem firmware to resolve your issue.
The one thing you might try to do is decipher the communication between the cards in order to understand the process. The BIM is tied to the modem through a serial interface. You could put a protocol analyzer in that line and see if you can document what happens as MDC call alerts are sent, acknowledged, not acknowledged etc. In other words, it is possible that the BIM sends the page command to the modem and no further communication takes place until the operation is completed - successful or not - in which case the modem firmware would be responsible for the retries.
On the other hand, you might see the BIM ask the modem to send the MDC signal each time the over the air signal is transmitted. In that case - one of the higher level processors would be doing the retries - either the BIM or the COIM.
If you can decipher the comm line between the BIM and the modem, perhaps you will learn something about MDC signalling that you could share here. When you send an MDC call alert from the console, the MDC modem transmits a dual MDC packet [276 ms.] Assuming that your console ID is 0001 [the default] and your target radio ID was 1234, the raw MDC data would be: 3589 1234 830D 0001. See if you can identify the data in the communication beween the BIM and the modem. Presumeably, the link format would also contain command codes, checksums, etc.
Thank you for your comments.
I've spent some time thinking about the process and reading what scant information I could get my hands on and pretty much concluded that most of the process takes place on the modem card.
However, your sugestion of monitoring the serial bus between the two is one I had not thought of and will probably give that a try.
I do have a special bim card wih a packet sniffer on it but it dumps all the traffic from the CEB out a serial port . You have to send the data to Schaumburg to get it analyzed. They havn't been any help on this one.
I know this project is a long shot but if we didn't try......
Thanks, William
I've spent some time thinking about the process and reading what scant information I could get my hands on and pretty much concluded that most of the process takes place on the modem card.
However, your sugestion of monitoring the serial bus between the two is one I had not thought of and will probably give that a try.
I do have a special bim card wih a packet sniffer on it but it dumps all the traffic from the CEB out a serial port . You have to send the data to Schaumburg to get it analyzed. They havn't been any help on this one.
I know this project is a long shot but if we didn't try......
Thanks, William
I did not suggest the packet BIM because I thought it would be hard to find one. Since you have one, I would suggest you create a test system - as simple as possible.
One card cage, one COIM, one timer, one BIM. Then put the packet BIM in that mini-system and watch the traffic. Maybe you can create a 'dictionary' of packet types for various actions. For example, you should see the BIM sound off once every four to five seconds.
Then you could have one computer screen monitoring the packet traffic and another screen [the protocol analyzer] monitoring the BIM to modem link.
Then see what happens as you send MDC. Even if the message content is not decipherable, you may be able to see a pattern of traffic that will identify which entity is responsible for the retries.
One card cage, one COIM, one timer, one BIM. Then put the packet BIM in that mini-system and watch the traffic. Maybe you can create a 'dictionary' of packet types for various actions. For example, you should see the BIM sound off once every four to five seconds.
Then you could have one computer screen monitoring the packet traffic and another screen [the protocol analyzer] monitoring the BIM to modem link.
Then see what happens as you send MDC. Even if the message content is not decipherable, you may be able to see a pattern of traffic that will identify which entity is responsible for the retries.