MOTOBRIDGE

ASTROMODAT · Post by **ASTROMODAT** » Sat Dec 18, 2004 8:43 pm

Motobridge looks extremely powerful. Does anyone have the details? For instance, how does it handle P25 IMBE trraffic? Does it stream IMBE over the Internet (that would be the best way!), or does it double vocode by using back-to-back DIU 3000's?

I hope that this is not just a matter of connecting dispatch consoles together over the Internet via one (or more) audio gateway bridges! If that's the bottom line, then we would have double vocoding for IMBE traffic, which doesn't sound too great.

An audio bridge that connects IP calls over the Internet would be an age old deal, that has been in wide use for well over 5 years now. My hope is that they are streaming the IMBE, or otherwise doing something new and sophisticated. Otherwise, this sounds a bit like the hohum Ham IRLP stuff. Nothing new or wonderful there. Hope I'm wrong, and it's something a lot better than this!

larry

Post by **/\/\y 2 cents** » Sat Dec 18, 2004 9:20 pm

guess what...it's not!

Cam · Post by **Cam** » Sat Dec 18, 2004 10:59 pm

The press release for those who may have missed it:

Florida First to Deliver Advanced Interoperability Features to First Responders with New Motorola Technology- MOTOBRIDGE™ IP Interoperable Solution

Florida State Technology Office First to Award Motorola Contract for a State-Wide Interoperable Solution Enabling First Responders on Disparate Networks to Communicate With Each Other

SCHAUMBURG, Ill. – 10 Dec. 2004 - A breakthrough in wireless communications technology may mean that public safety agencies will no longer wonder whether they will be able to talk to each other when they arrive at an emergency scene.

“MOTOBRIDGE IP is a huge step for Florida’s homeland security efforts,” said State Chief Information Officer Simone Marstiller. “By connecting users and allowing them to communicate in ways not possible before, the system will strengthen Florida’s security.”

With Motorola’s (NYSE:MOT) new soft switch technology, MOTOBRIDGE IP, agencies at any government level will have the ability to talk with one another regardless of the type of systems or frequencies they normally use. Because of its advanced IP-based design, users also can access many of the additional features they regularly depend on such as Emergency Unit Identification.

“MOTOBRIDGE redefines the concept of the gateway switch,” said Mark Moon vice president and general manager, for Motorola. “Until now, the issue was having to accept the limitations of a specific switch. This soft switch technology erases most of those limitations and bridges the communications gap. It responds to the two key concerns of public safety agencies everywhere—capability and cost.”

Historically, a gateway switch provided a simple, economical way to create a voice link between different communications systems so that personnel at an emergency or large event could talk with one another. The interoperability these gateways created was invaluable, but the limitations also were significant. Gateways typically do not provide advanced calling features such as emergency identification and have few if any system management features. Typical gateways also suffer from having a single control point that would terminate interoperability if a failure occurs at that point.

“MOTOBRIDGE is a feature-rich addition to our Mission Critical IP network portfolio,” Moon said. “It delivers the flexibility and interoperability agencies need, plus many of the capabilities they want that are usually found in far more sophisticated and more expensive approaches.”

Among its many technological and configuration advantages, MOTOBRIDGE:

* Uses standard IP protocol
* Operates over mission critical and commercial IP networks
* Offers distributed control points to ensure that there is no single point of system failure
* Can be implemented by agencies of any size and can be expanded as needs change
* Provides robust system management tools for administrators to monitor and manage the system

The flexibility and sophistication of MOTOBRIDGE also means agencies have innovative communications options. For example, dispatch centers throughout a network or across different agencies and jurisdictions can be connected quickly, allowing full duplex conversations for better coordination among dispatchers. Also, because the IP-based technology displays the identification of all units operating on the network, dispatchers know instantly which field units are requesting assistance. Agencies using deployable communication vehicles also can be linked to the network while on scene, using standard IP connectivity.

“MOTOBRIDGE helps agencies to dramatically increase their interoperable communications capabilities immediately, even as they consider more sophisticated solutions for the future,” said Moon. “If an agency chooses to move to a system-specific roaming or standards-based shared solution for its routine communications in the future, the agency still can use its MOTOBRIDGE system to connect with other agencies responding to an emergency. That capability alone may make MOTOBRIDGE one of the most important communications tools available to any public safety agency.”

ASTROMODAT · Post by **ASTROMODAT** » Sun Dec 19, 2004 1:23 am

By now, I think we've all seen the various huge Motorola press releases on Motobridge, as it has been splashed all around the Internet like some sort of big blockbuster movie trailer release. The question on the table is: What are the details and specifics of Motobridge?!

For example: What are the details of the hardware and software that make up the gateway? Is it just a piece of $40,000 software that runs on any ol' Windows 2003 server, or what is it? What is involved with the actual hardware (outside of the server PC and software) that provides the audio bridge? What is a typical cost for the hardware and software for a small, medium and large Motobridge system? What is its architecture and system flows that support interconnected P25 IMBE traffic? Do IMBE mode interconnects resort to back-to-back (double) vocoding? Can individual radios interconnect to other specific individual radios (perhaps privately) on a distant system(s), or does Motobridge simply interconnect complete systems via console audio bridging? Can the bridge support bridging of more than 2 systems at a time? What are the limits? Are interconnect arrangements created at the console points by manual procedures by the Dispatch folks, or can a radio in the field set up flexible interconnects between systems, on-the-fly/real time via DTMF and/or Data 12 packet commands? Are interconnects limited to pre-canned system connection scripts, or can such interconnects be set-up via a large set of possibilites, based on real time commands, as limited only by the actual systems on the network? How are latency issues handled, and what limitations do these considerations impose? How are data and voice collisions handled? How is the signaling passed (such as the Unit IDs that are referred to in the Internet press release articles)? How are COS, PTT, Proper PL Detect, and the like, passed between repeaters, and how does this get coordinated to avoid collisions without a repeater controller? What about encryption? Can the radio traffic remain secure, end-to-end, and if so, how is this IMBE traffic passed? If not, does each system have to decrypt its transmissions at their respective DIU 3000 before passing them on to the other system(s)? If Yes, how many back-to-back interconnects are possible before the traffic is unusable due to multiple vocoding distortion at such back-to-back DIU interconnect points? The Internet articles allude to the use of a standard IP protocol. Are they referring to VoIP, or to some sort of an alternative approach? Assuming that Motobridge is dual mode (e.g., IMBE as well as legacy analog FM), what are the interconnect transmission facilities requirements between the DIU 3000 and the Internet (e.g., is there a hardware box that sits between the DIU and the router?). Although I suspect any generic FM radio will work "as is," are there any unique issues for IMBE radios (such as new signaling protocols, and the like) that may necessitate new CPS and/or firmware uplifts in the P25 subscriber sets to unleash the full power of Motobridge? (I can see it now: Motorola pushing wheelbarrows full of Motobridge new cash revenues to their gigantic bank!)

My sense is that this thing is so darn new that probably no one knows the answers to these basic questions, outside of the Motorola Motobridge design team and sales folks. I know that a lot of folks on this board are capable of making lots of educated guesses about how Motobridge works, but I'm asking if anyone has sat through an actual Motorola Motobridge presentation, and/or if anyone here has read any detailed Motorola literature that may shed some light on these questions.

Sure would appreciate any details, if and when someone on the Batboard finds out. To be realistic about this, I suppose we'll need to wait for the Motorola Motobridge System Guide to be published to get answers to these questions. Darn!!

Thanks, in advance, for any possible help that someone might be able to provide. This Motobridge thingy is so big that perhaps it will rate its own Batboard special category!

larry

Post by **/\/\y 2 cents** » Sun Dec 19, 2004 7:09 pm

I know exactly what it is because I've seen the software in person, it's quite inferior to ours, but I give them credit for making a decent knockoff....it's a 40,000$ version of what I have and im going for their throats in about 10 hours. I have quite a bit of internal documents on this one including all of their sales presentations and even the name and background info on the CGISS salesman who sealed the deal with the state of florida. I will be showing the state Technology officer in my home state of florida just how moto ripped off some good people trying to start a business 20 minutes up the road from the LMPS. Let me just say our product has many similarites and features that we pioneered and I have video tapes of when some of the Moto people came to look at my prototypes.

Oh yeah larry (ASTROMODAT), now that mototrola endorses and is running scared to get a version up and running of what I created and was telling you about do you sort of see why I told you it was so great and better than ASSTRO. Now that motorola's on it, I bet you are reconsidering your position. It's radio's holy grail my friend, I kid you not.

Post by **batdude** » Sun Dec 19, 2004 7:34 pm

i bet their lawyers are better than yours... and they have more of them.

sorry man, if you are right, then you committed the first sin in this fast paced world.

YOU MISSED THE MARKET.

i wish you well in your legal battles.

doug

Chrisjz · Post by **Chrisjz** » Mon Dec 20, 2004 6:31 am

M/A-COM was the first to introduce this several years ago as their Network First product, Motorola has been playing catch-up ever since. I was at the show when it was unveiled and there were many Motorola reps asking about it, they also wanted to see it but M/A-COM would not let them within 10 feet of it, understandably so. This is nothing new but I'm sure Motorola will tout it like they invented it or were the first to introduce it. Looks like you are going to have to take on M/A-COM too /\/\y 2 cents...

http://www.networkfirst.com/resources/p ... ed5_03.pdf

ASTROMODAT · Post by **ASTROMODAT** » Mon Dec 20, 2004 12:51 pm

How does "Network First" handle digital voice? Does it D/A to analog at the console, and then VoIP it over the Internet, or does it stream it as digital over the Net? If it is the former, then it suks, as it is no better than crummy IRLP. If the latter, I'm very interested.

larry

ASTROMODAT · Post by **ASTROMODAT** » Mon Dec 20, 2004 3:58 pm

Thanks for the URL to the Network First site, Chrisjz. I appreciate this tipp-off, a lot. I read M/A-COM's Network First brochure that is featured at this site. It appearss to indicate that the console ANALOG audio is converted into packet data, and then launched over the Internet using the popular VoIP protocol. I assume that M/A-COM has a box similar to a DIU 3000 for their digital voice mode.

This approach where analog audio is packetized and sent VoIP over the Net is a now very dated analog cheapie "solution." It should works quite well for legacy analog FM stuff, since there is no double, tripple, quadrupple, etc. vocoding going on. Analog to VoIP is essentially what the Ham IRLP stuff does, as well as a plethora of other inexpensive stuff, such as X-Box, etc. This approach is absolutely no good for IMBE, as you have a minimum of double vocoding, which doesn't sound so hot. Multiple vocoding (especially anything in excess of double vocoding) is essentially worthless for IMBE operations from a practical standpoint, unless one can live with unrecognizable voices, etc. The recovered audio quality (after anything more than double vocoding) would be bare bones, resulting in horrible quality communications audio.

I am assuming, but don't know for a fact, that MOTOBRIDGE is like this (e.g., IMBE audio is D/A'ed by the DIU 3000, then sent in analog form over to the console, packetized, and then finally launched via VoIP protocol over the Net. The distant end would be a mirror image). Double vocoding would barely support this simple, point-to-point scheme. Any arrangement involving more than 2 consoles would necessitate more than double vocoding. This is my assumption as to how MOTOBRIDGE works, too, until we can get the MOTOBRIDGE brochure.

If that is true, my hat is REALLY off to ICOM, since their D-STAR system launches the AMBE digital voice over the Internet, with no vocoding until it reaches the final radio's AMBE vocoder. ICOM somehow figured out how to stream AMBE over the Net, which had to be a big R&D effort. No one else that I am aware of is able to do this. It may be that a piece of this R&D was undertaken (at least in part) by the D-STAR standards board in Japan.

The more I see of this VoIP junk, the more respect I have for ICOM's true 100% digital approach. They ought to consider working a business deal with Motorola to apply their D-STAR 100% digital system to Motorola's P25 radios, using ICOM's Internet 100% digital solution. That would be a really slick arrangement. Maybe Motorlola could simply buy ICOM. Hum......

larry

mr.syntrx · Post by **mr.syntrx** » Mon Feb 21, 2005 2:48 am

If both ends are using P25, you could grab the the raw voice data and send it to the remote end without decoding or processing it. Decoding the IMBE voice and encoding it in another format would only really be necessary if the remote end was running something other than IMBE (e.g analogue.)

ASTROMODAT · Post by **ASTROMODAT** » Mon Feb 21, 2005 10:37 am

Easier said than done, mr. syntrx! In recently speaking with the Engineers at DVSI, to their knowledge, to date no one has a product available that can stream IMBE over the Net. Only ICOM's D* product is currently capable of streaming digital voice end-to-end over the Net, and this is AMBE 2020. Not to say that someone may someday choose to build and market a box that will stream IMBE over the Net, but to date no one has yet done this. It's too darn bad that ICOM's product isn't IMBE. Think of the commercial applications. MOTOBRIDGE currently involves the typical VoIP approach, and they told me that while streaming end-to-end IMBE could conceivably be a future possibility, this would require a plethora of their customers to demand this capability (and be willing to pay for it). My sense was to not hold my breath.

larry

Post by **alex** » Mon Feb 21, 2005 10:41 am

I still maintain my throught that you could build your own setup to do this.

IMBE is straight data. Why not build a data slicer that allows you to record the digital data, and then transmit that over the "net" to another box that rebuilds the data and sends it out. There would be no "reverse engineering" of the protocol, just data in, data out. You'd have to probably write something that would guarnetee the error correction on both ends to be 99% accurate, but in theory, this would work.

From my limited understanding, it's just 9600 baud data. This would even move secure voice as well.

You'd then be left to figure out how to then dump it back out over the air.

-Alex

ASTROMODAT · Post by **ASTROMODAT** » Mon Feb 21, 2005 1:25 pm

Fist off, you would have to determine where to pull the IMBE data. Where would you intercept the digital data stream in the DIU3000? At what point and where? What signal level would be proper? Keep in mind that the DIU3000 does not have an IMBE port, so to speak. You would have to tear into its internal circuitry and Motorola does not sell the maintenance manual to anyone. These blue line manuals reside in Israel, so lots of luck trying to intercept the "raw" IMBE!

Next, you would have to decide if you want to packetize the data, or not. If you decide to packetize it, what would be the size of the header(s), and how many headers would be needed? What about the trailer---what size and how many? Next, what size would the actual data packets be, and how many per train? What format would you use? What would your protocol be? X.25 is way too slow for good quality voice, so what protocol are you proposing? Would you attempt to have it standardized? What about an FEC system? What would be its design characteristics? Would you attempt to adapt an off the shelf FEC? What speed would your FEC run at, and how much bandwidth would you propose to allocate for FEC functions? To give you an idea of the complexity of ICOM's FEC for running AMBE over the Net, they recently made a small change in their FEC algorythm and it took them over 6 months to re-design, test, and implement it.

Then you would have to decide on how to address the packetized IMBE. How would you propose to handle the source addressing scheme? What type of protocol would you use for the source address? Would you design a new one, as did ICOM, or attempt to modify someone else's protocol? What about the target addressing? What about their associated protocols? Would you interface to the Net via VPN tunneling? What would your format and protocol be? Would you do like ICOM and use A-net? If you did this, then like ICOM, your servers would need to be connected with very high end modems to support such an addressing scheme, such as the Linksys model that they are using (at $250 each). Also, what about the software that would be needed to run the server at each end? Would you opt for Windows 2003 server software, or use Linux as did ICOM?

These are but a tiny subset of the thousands of issues that would need to be discussed and decided upon, and then designed, tested and implemented. Would you implement this logic in DSP? How many $100,000's of $'s would that cost for the first DSP? I would expect that you would need a fairly sizable team of engineers to do this, and a few years of time. Don't forget what Motorola told me. The R&D involved to stream IMBE over the Net is substantial, to the point where they would need very strong customer requirements to make the sizable R&D investment worthwhile. This is not something a few people will do in their basement in 6 months time!

Keep in mind that ICOM has done something quite similar, and it involved many EEs and 6 years of time, yet their D* repeater (that works hand-in-glove with their controller to stream the AMBE) is still not on the market. Much of their R&D went into the design of the controller and the server software whose primary purpose is to take the AMBE input and send it over the Net. Designing a system that could stream IMBE would be equally complex, and ICOM's design details are highly proprietary, and well protected.

larry

Post by **alex** » Mon Feb 21, 2005 2:01 pm

You and I are looking at this on two completly different levels.

This might be mostly due to my level of understanding, but lets take a wide angle look at it.

I'm not looking to engineer the protocol - change the voice around - all that sort of stuff - all I would in theory want to do is make one signal go in at point A, and come out at Point B.

If I create a device of some sort that is able to do that - and then reproduce it on the other end, then I don't need expensive this that and the other. This is all stuff that goes over the air. As long as you "capture the essance" and reproduce that "essance" at another location (and it's modulated correctly), there's no reason why it won't work.

Hey, Like I said, I don't know how a DIU works, etc, but I'm not even thinking about tapping off of it or anything like that - I'm talking pull the data out of the air - or before it hits the air, encapsulate it in it's modulated form, throw it over the internet, and then remodulate the captured data over the air however you want.

I think you and I are both on different levels with this who thing.

Maybe I should put it this way.

You pick up the phone, dial a number, send some tones through, and hang up. You should (providing you were able to completly capture the tones) be able to decode them on the other end right?

That's how a modem works...

What's to say you can't do the same thing with IMBE data.

Now, apparently there is such a beast known as an Astro Modem? You can send the data through that?

I don't know all the in and outs, I don't pretend to know, but I offer up an interpratation.

-Alex

Post by **batdude** » Mon Feb 21, 2005 2:31 pm

not to be a player in this exchange of ideas

but

9600bps "raw" astro data is available out of either an astro modem or a V.24 board.....along with all the other things (ptt, cor, etc)

doug

ASTROMODAT · Post by **ASTROMODAT** » Mon Feb 21, 2005 4:20 pm

One more time, then I give up...

I spoke with Motorola about sending the IMBE stream over the Internet, just like you want to do. I'm pretty sure they are aware of their own ASTRO modem, etc. They told me the same thing that DVSI Engineers had told me a few days prior: "No one to date has a box that can stream IMBE over the Net." Motorola also said that the R&D to do this is significant, and they would only make the investment if enough of their customers indicated a willingness to pay for such a device, including recovering its R&D associated with developing such a box. If it was so simple as you suggest, I'm sure Motorola wouldn't be talking about "significant development costs."

I wish it was a simple task, as connecting streaming IMBE over the Net would be a tremendous capability.

larry

mr.syntrx · Post by **mr.syntrx** » Mon Feb 21, 2005 4:32 pm

alex wrote:I still maintain my throught that you could build your own setup to do this.

IMBE is straight data. Why not build a data slicer that allows you to record the digital data, and then transmit that over the "net" to another box that rebuilds the data and sends it out. There would be no "reverse engineering" of the protocol, just data in, data out. You'd have to probably write something that would guarnetee the error correction on both ends to be 99% accurate, but in theory, this would work.

From my limited understanding, it's just 9600 baud data. This would even move secure voice as well.

You'd then be left to figure out how to then dump it back out over the air.

-Alex

That's a better worded version of what I was saying.

mr.syntrx · Post by **mr.syntrx** » Mon Feb 21, 2005 4:46 pm

There's nothing complicated about grabbing raw data coming into a computer's serial port from a DIU via V.24/RS232, and piping it straight off to somewhere else via the Internet, without decoding or processing the datastream. I've got the software on my UNIX box to do this right now, in fact ('cat' and 'netcat').

(If someone donates a DIU-3000 and a UHF Quantar I'll be happy to demonstrate it

)

I assume MOTOBRIDGE does something other than just send raw ASTRO data without processing it. It's hard to tell exactly what it does, because of the massive lack of public documentation on it.

ASTROMODAT · Post by **ASTROMODAT** » Mon Feb 21, 2005 5:29 pm

As VP Cheney kept telling John Edwards, where do I begin?!

If streaming IMBE over the Net was as simple as you think, don't you suppose Motorola would also be aware of this, since they are the ones who designed the DIU3000? Do you really think Motorola's comments about "significant R&D to accomplish this" are relevant if it is such a trivial matter? Would you suppose that if you could simply plug in one port from a DIU to a PC and send it oveer the Net to a mirror arrangement on the other end that perhaps Motorola would be aware of this?

There is no way that the Motorola engineers misunderstood me. I asked them about being able to interrface two DIUs via digital end-to-end connectivity over the Net, as opposed to using VoIP techniques as does MOTOBRIDGE. They knew exactly what I meant, and they had considered this when developing MOTOBRIDGE. The associated R&D was so signifcant that they did not develop this capability.

larry

Post by **alex** » Mon Feb 21, 2005 9:03 pm

While I'm sure that Motorola Engineers are more skilled and smarter than I am with respect to how this stuff works, I think the larger thing here is:

What one person says can't be done, is another person's challenge.

The problem is - It's never been tried. None of us have the equipment, tower space, whatever, in order to proove it's success. I'm also not for the purposes of my vision going to say that a DIU is required either - I don't know what it's primary purpose is, and frankly - take it out of the equasion.

Regardless, I'm sure it can be done. I'm also sure that it's cost prohibitive to do. You don't see many Quantar w/DIU setups being sold on ebay.

Someone send me a uhf 450-512 unit that will go into the ham band, and a DIU. I'll happily play around in some spare time with making this work with a couple of unix machines.

I'm SURE it can be done. I'm sure it will have it's challenges... But that's what the idea about doing amateur radio - spending the time to bend the norm a bit.

For the Motorola Engineers - it's just not practical. Sending this information over the Internet (besides obvious security risks) is just not as reliable as Public Safety demands, so you will probably not see something for a while that would support this in a high tier product.

Like I said above - I do NOT claim to be the know all bottom line end of knoledge - i'm FAR from that. I take in what I read here, match it up with what I know, and hope that it comes out in a readable format, and maybe it'll make sense.

-Alex

tvsjr · Post by **tvsjr** » Mon Feb 21, 2005 9:54 pm

alex wrote:While I'm sure that Motorola Engineers are more skilled and smarter than I am with respect to how this stuff works, I think the larger thing here is:

What one person says can't be done, is another person's challenge.

The problem is - It's never been tried. None of us have the equipment, tower space, whatever, in order to proove it's success. I'm also not for the purposes of my vision going to say that a DIU is required either - I don't know what it's primary purpose is, and frankly - take it out of the equasion.

Regardless, I'm sure it can be done. I'm also sure that it's cost prohibitive to do. You don't see many Quantar w/DIU setups being sold on ebay.

Someone send me a uhf 450-512 unit that will go into the ham band, and a DIU. I'll happily play around in some spare time with making this work with a couple of unix machines.

I'm SURE it can be done. I'm sure it will have it's challenges... But that's what the idea about doing amateur radio - spending the time to bend the norm a bit.

For the Motorola Engineers - it's just not practical. Sending this information over the Internet (besides obvious security risks) is just not as reliable as Public Safety demands, so you will probably not see something for a while that would support this in a high tier product.

Like I said above - I do NOT claim to be the know all bottom line end of knoledge - i'm FAR from that. I take in what I read here, match it up with what I know, and hope that it comes out in a readable format, and maybe it'll make sense.

-Alex

I think Alex is getting at something much lower level than a DIU.

Represent a voice frame as 10101010b (obviously, this is just academic discussion), and the analog representation of this voice frame as f(x).

A DIU will receive f(x) from the Quantar, convert that function into the voice frame, then, using the proprietary DVSI codec, decode this to voice. There's nothing special here until the DVSI codec and decoding to voice is involved. The decode from analog to the digital data is nothing more than decoding 4-level FSK (C4FM) or the narrowband CQPSK.

A simpler device would stop before applying the DVSI codec and converting to digital. The analog data would be processed to digital, and that data transmitted across whatever sort of medium you'd like ('net, leased line, I2, etc.) The unit at the other end would simply spit the bits back out. DVSI's codec would never be involved.

Technically, if you could record 0-5KHz at a sufficient sample rate with a totally flat audio response, then play it back somewhere else, the receiving unit would never know the difference. You're doing the same thing, just adding an A-->D/D-->A step in there.

You also avoid double vocoding, etc. I believe this is exactly what Icom is doing with DSTAR.

mr.syntrx · Post by **mr.syntrx** » Mon Feb 21, 2005 10:00 pm

I have a long bus ride every day, but it's good for thinking about stuff like this

There is only one reason why this might not work, and that's latency.

If the protocol Motorola uses for V.24 links only allows for very short delays between when it sends a signal, and when it expects a reply from the other end, it won't be able to cope with going across the Internet (it'll time out).

tvsjr · Post by **tvsjr** » Mon Feb 21, 2005 10:38 pm

mr.syntrx wrote:I have a long bus ride every day, but it's good for thinking about stuff like this

There is only one reason why this might not work, and that's latency.

If the protocol Motorola uses for V.24 links only allows for very short delays between when it sends a signal, and when it expects a reply from the other end, it won't be able to cope with going across the Internet (it'll time out).

My guess is that, for critical infrastructure, you wouldn't be pushing it across the Internet... more likely, leased lines or an existing data infrastructure (microwave, etc.)

I sure wouldn't want to explain to de big boss why the fancy ASTRO system went down because the Internet took a dump...

mr.syntrx · Post by **mr.syntrx** » Tue Feb 22, 2005 12:24 am

tvsjr wrote:
mr.syntrx wrote:I have a long bus ride every day, but it's good for thinking about stuff like this

There is only one reason why this might not work, and that's latency.

If the protocol Motorola uses for V.24 links only allows for very short delays between when it sends a signal, and when it expects a reply from the other end, it won't be able to cope with going across the Internet (it'll time out).
My guess is that, for critical infrastructure, you wouldn't be pushing it across the Internet... more likely, leased lines or an existing data infrastructure (microwave, etc.)

I sure wouldn't want to explain to de big boss why the fancy ASTRO system went down because the Internet took a dump...

That's right. With a well built private IP network on which you could guarantee QoS you'd be OK, and I think that's really what /\/\ is intending for MOTOBRIDGE.

Post by **alex** » Tue Feb 22, 2005 6:40 am

Yup - you guys are getting what I'm getting at.

Try something simple. IF that doesn't work, try something more complex.

Either way - you can do this, probably rather inexpensivly - you just need the right data slicers, and a way to make it "pop" out the other end over the air correctly.

I don't think it would ever know about latency unless your sending calls, where the radio would time out before the signal might hit the other radio, and bounce back. Considering it's a VERY fast 9600bps when sending data through voice, the time that is needed for a response would probably be minimal.

Either way, it would be VERY cool to try, but, lacking such equipment, it'll remain a pipe dream.

-Alex

ASTROMODAT · Post by **ASTROMODAT** » Tue Feb 22, 2005 8:50 am

The problem with the complexity of streaming IMBE over the Net has nothing to do with issues of the Net's reliability/availability. MOTOBRIDGE is designed and marketed to be used over the public Internet, as well as private nets, based on customer choice. I have the Motorola advance literature and brochures on MOTOBRIDGE and they make this very clear.

larry