My last 2 projects included custom equipment attached to the 2nd rs232 of the modem and was thinking about the RTE to be able to simulate that 2nd RS232 as some of the com ports in the computer. That will greatly speed up the development.
If I understand correctly, you’d like to connect your “custom equipment” to one of the PC’s UARTs, rather than connecting it to the module’s UART2 (and by the way addressing it transparently through the ADL APIs)?
Well, I don’t see the avantage of such a solution…
Or maybe you mean you’d like to simulate the complete equipement (without connecting the hardware one), but still using the ADL APIs to address it?
The general idea is: you connect the modem to the PC on COM1 and set modem’s 2nd RS232 to be “simulated” on PC’s COM2, so when you do RTE debug, all ADL calls to and from UART2 are going through PC’s COM2. Advantages:
- No additional hardware needed - when you want to connect the modem with another serial device, that device usually can already connect to PC, so it is a matter of plugging the modem to the pc, attaching that device and you are ready to make your first communication
- Easier communication debug - there are a lot of programs that allows you to do nice logging of the communication happening on some port, giving better experience than traces
Of course, thats an extremely low priority request, after you have done everything you can imagine, wait a month, and still can’t get anything more to do on the m2mstudio then remember about it 
I think the fundamental problem here is that the RTE mode does not simulate anything - all the real hardware stuff still happens on the real GSM device!
It’s just your application that executes remotely - making remote procedure calls to APIs on the actual GSM device.
That’s why you have to have a real GSM device.
Note, however, that you can route UART coms through the PC.
This should be illustrated here, but the forum seems to have lost the picture:
forum.sierrawireless.com/viewtop … com#p11123
I’ll see if I can find it again…
Interesting. There is no more such topic in the manual (or at least wasnt able to find it) as you mentioned in the other topic. For the current project, I’ll get modified cables/modem today and be over with, but for some strange reason I’m always getting projects that require to attach something to modems, and if there is an alternative route in the future, I’ll be happy panda
This information used to be provided in the “Tools Manual For Open-AT IDE” - but that document is no longer included in the downloads, and the information is not provided in any of the M2M Studio docs (not that I’ve been able to find, anyhow).
This was the illustration of how the Remote Execution works:
And this was the illustration of passing UART debug through to a PC COM port:
Thanks, I’ll try something for the next project. I suspect, however, that this info will be totally outdated then, I have read somewhere that wav…sierra wireless is actively trying to get rid of selima (which, looking at the number of warnings it gives, and the fact it requires admin priv here to even run I wholehearty agree)
It’s true that we’ve not integrated in the studio documentation the stuff you are talking about (concerning RTE mode general architecture and others). We will update that.
About the feature which allows to “bridge” data between the PC’s COM ports, it’s true that we are working on removing Selima, but we will pay attention to keep this functionality (or at least restore it, since it was “lost” in the current studio implementation).
Excellent! 
This is (or would be?) an extremely valuable facility!
It would be even more valuable if you could route directly & easily to a virtual COM port - so that you could connect direct to an app on the same PC, without having to “loop” a cable between physical COM ports.
(sure, you can currently do it with some 3rd-party stuff - but I don’t count that as “direct” nor “easy”)
We will however have to implement something like this to keep backward compatibility with current RTE mode, as this one requires Selima (we’ll need to route Selima to a virtual port plugged on the Studio, as the physical COM port will be locked by the new studio implementation itself).
So if we have it internally, it makes sense to open the feature to our dear users 