I stumbled across this while looking around and thought it would come in handy in certain situations. I am however getting an error while entering login information for the modem and I am pretty sure it's the $ in our password. The error is: Run-time error '13' Type mismatch
I tried typing in other random passwords without the $ sign and it seems to take those fine. We have our own teleport and I suppose I could just change the pass for all modems but thought I would ask first. Hope you don't mind me barging into this thread.
Originally posted by Darren: Hope you don't mind me barging into this thread.
Not at all - we would like to have this tool work for anybody, but we need feedback on what doesn't work with non-Ethersat systems. I will look at the code and see if I can figure out what is happening.
On a quick test I could not create a password that threw an error, including those that contained $ signs at the beginning, or middle, or end. If you wouldn't mind my seeing your password please e-mail it to me using the link at the bottom of this page.
Sorry for the delay Don. I was out of the office on Friday. Now that I think about it the random passwords I typed in would not have allowed communication to the modem since they were wrong. So it seems once communication is established is when the error hits. The power/snr bars do show correct values but of course are frozen due to the error. I'll play around with it a little more in my lab.
Please don't feel the need to work on this. I was just hoping it would make my job easier when at the remote end or too lazy to call into my NOC when on the road
In case you are curious we use iDirect 3100/5100 modems, Motosat XF3 and Mesa units with D3/D4 controllers.
Thanks for taking the time to respond!
Posts: 6 | Registered: Feb 2010
| IP: Logged |
I know programs always have bugs, but I hate to leave any when they have been pointed out.
I agree it does not appear to be a password issue. Most likely it occurs when we try to adjust the TX bar to fit the range for that modem.
Is it possible that your options file allows for a TX Power value greater than zero? I think the code assumes the value will be 0 or some negative number, so a positive value would be out of range, and that would explain the error.
The telnet command to see allowed power is options show ACM
Darren, I would appreciate it if you could download version 1.0.27 that I put up this morning. Operational code is unchanged, but it has debugging messages if any error occurs. Message would read "Error in section xxxx. String was xxxxx."
When the OK button on the message is clicked the program will terminate. The String will be the data read via telnet from either the modem or the controller, and the section will be something like Tx Power, or Rx SNR.
With luck we will get a message that makes it clear to me what data is not being correctly handled.
Interesting. We are looking for satellite identification info here, and yours may not have that. If you could telnet into the modem and issue the options show SATELLITE command it would be helpful to know if anything is there besides min_look_angle
For me at the moment it looks like this:
> options show SATELLITE [SATELLITE] name = AMC 15 channelname = AMC 15 longitude = -105.000000 hunt_frequency = 0.000000 polarity = H noise_reference_frequency = 0.000000
I'll rewrite the code to trap issues when the expected values don't occur.