Remote Rig
RRC 1258 Support in English => General discussion forum => Topic started by: K5WA on 2011-05-09, 15:22:22
-
Do you have any software to unlock my 1258? It was working fine until I changed the IP from static to DHCP. Now, the red light flashes constantly and Set Up Manager is unable to "see" the 1258 even with a direct connection to the USB port. The driver shows that it is working properly, but there is no communication and Set Up Manager does not recognize the 1258. I have tried the reset button on the 1258 thinking that the reset button would put the 1258 back to its original state but that is not happening.
What else can I try to make it work?
Also, I still have not gotten my micro RRC client to work correctly. The audio cycles on and off as the buffer bar moves from left to right. Does the new software update fix this problem?
Thanks for any help you might have.
Bob Evans, K5WA
-
I answered this to you by email yesterday, didn't you get it?:
"It appears the RRC is constantly resetting itself, thus preventing it from working normally. Without USB connected, is the red light flashing then too?
Did you use Setup Manager when changing to DHCP? Which firmware version is in the RRC? And did you try a "long reset" too?
There are other things to try too, but as its weekend I am not at work, so that would have to wait another 24 hours or so, that also includes the RRC micro client."
-
Jan, no I did not receive any replies. I have checked my SPAM filter and it is not there.
Yes, the red light still flashes when the USB cable is removed.
Yes, I used Setup Manager to change to DHCP. The firmware is 2.35.
I did a search of the manual and do not see "long reset" mentioned. I have held the reset button for 10 seconds with no response. Do I need to hold it longer than 10 seconds?
Thanks,
Bob K5WA
-
Have you had any problems using Setup Manager(before when the unit worked)? For ex. not being able to update the firmware using it? I ask because v2.36 and newer fix an USB error we have been hunting down for a long time which could cause USB operations like firmware update to fail.
On page 17 of the user manual you will find information about what I called the "long" reset. You will have to press and hold the reset button(without releasing it the tiniest bit) for at least 15-20 seconds or until all LEDs start to flash fast. Doing so will put most of the settings back to their initial state, so you will have to setup the unit again.
-
The long reset did not change anything. I held the reset button until the green, red and yellow lights all flashed for 45 seconds and then released the button. The green light still continues to blink with no stopping after it powers up again.
I had not had any problems with this unit (1258IIS) until this current issue but I had to send my 1258II (no S) unit back to Sweden for Mike to reset because it locked up when I accidentally loaded the WebSwitch firmware into the 1258II. I now have a pair of 1258II and a pair of 1258IIS and have had trouble with all of them. There should be some way for me to reset the unit back to factory default.
-
Strange... The long reset is supposed to bring the unit back to factory default. What about the other questions I asked you?
Would it be possible for you to connect a RS232 cable between COM1 on the RRC and a serial port on a PC, and run a terminal program in 38400,8,1 no parity while attempting to boot up the RRC in order to see the startup printouts it does?
-
I answered all the questions you asked.
I will try a direct terminal connection to COM1 on the RRC and my PC to see if I get any output.
Back to my original question...is there any software to unlock the RRC?
-
I answered all the questions you asked.
I will try a direct terminal connection to COM1 on the RRC and my PC to see if I get any output.
Back to my original question...is there any software to unlock the RRC?
If you answered this:
Have you had any problems using Setup Manager(before when the unit worked)? For ex. not being able to update the firmware using it?
then I did not understand it ;)
I don't understand why you keep asking about software being able to "unlock the RRC"? Unlock from what? I thought we were trying to figure out why your RRC is what you call "locked"? In the context of how you are describing it, it seems that that RRC is in some strange condition which prevents it from executing its firmware in a normal manner, therefore it might appear "locked". A similar situation happened when your RRC got a Webswitch firmware, that firmware was unable to execute normally in the RRC and therefore repeatedly rebooted which made it look "locked". Or are you asking for something different I haven't understood?
-
No, I have not had any problems using Setup Manager prior to this issue. I never changed to DCHP before and that seems to be what caused it to "lock up". I call it locked up before I can neither get in or see any output. I will need to use DHCP since the control RRC will be moved to different networks over time and needs to adjust automatically.
-
OK, so the direct terminal connection to COM1 on the RRC would be the next thing to try. If something shows up there please copy and paste it here. An example of a normal startup could be:
==========================================
** 1258 Bootloader V1.9 **
** Booting application **
==========================================
** Press capital x for xmodem apploader **
==========================================
Company : Microbit
Product : 1258
Hardware : 6
Software : 2.39
Bootloader: 1.9
Compiler : 4.1.1 (WinARM)
Build : May 4 2011 15:47:02
ROM/RAM : 359424/54352
ethRAM : 2944 (max 3kB!)
USBRAM : 0
ResetSrc : 4 [3]
Uptime : 0
=========================
HW-device = 32
CW-pot = 1023
Debug level = 0
Control panel = 0
Program mode = 4 - Yaesu, Kenwood, Elecraft
PID = 0
Setup length = 673
=========================
codec = WM8985
audio = BOTH_OPEN
duplex: New Audiocoding 102 (8 KHz)
phy = KSZ8041NL
USB cable disconnected
USB cable disconnected
eth link up (100FDX/MDI)
-------------------------
mac : 00:50:c2:11:93:3e
ip : 192.168.137.156
netmask : 255.255.128.0
gateway : 192.168.128.1
dns : 192.168.128.1
-------------------------
Telnet: Listening on port 23
HTTP: Listening on port 80
-
I got output from COM1:
==========================================
** 1285/1258 Bootloader V1.8 **
** Booting application **
==========================================
** Press capital x for xmodem apploader **
==========================================
setup load error
Company : Microbit
Product : 1258
Hardware : 6
Software : 2.35
Bootloader: 1.8
Compiler : 4.1.1 (WinARM)
Build : Mar 17 2011 11:06:54
ROM/RAM : 355948/54236
ethRAM : 2944 (max 3kB!)
USBRAM : 0
ResetSrc : b [3]
Uptime : 0
=========================
HW-device = 0
CW-pot = 260
Debug level = 0
Control panel = 1
Program mode = 4 - Yaesu, Kenwood, Elecraft
PID = 4
Setup length = 673
=========================
enable : 0
speedWpm : 0
iambic : 1
paddleReverse: 0
weight : 30
sideToneHz : 800
sideToneDb : 20
lfDelayMs : 0
keyDelayMs : 0
codec = WM8985
audio = BOTH_OPEN
duplex: New Audiocoding 102 (8 KHz)
phy = KSZ8041NL
USB cable disconnected
USB cable disconnected
-
As an additional experiment, I tried to see if I could get COM1 output on my older 1258II (non-S type) because it had the same problem as my new RRC. Here is the output from the older one:
==========================================
** 1285/1258 Bootloader V1.5 **
** Booting application **
==========================================
** Press capital x for xmodem apploader **
==========================================
Using default profile
Company : Microbit
Product : 1258
Hardware : 5
Software : 2.34
Bootloader: <= 1.7
Compiler : 4.1.1 (WinARM)
Build : Feb 14 2011 16:23:14
ROM/RAM : 341840/52964
ethRAM : 2944 (max 3kB!)
USBRAM : 0
ResetSrc : b [3]
Uptime : 0
=========================
HW-device = 0
CW-pot = 1023
Debug level = 0
Control panel = 1
Program mode = 4 - Yaesu, Kenwood, Elecraft
PID = 0
=========================
enable : 0
speedWpm : 0
iambic : 1
paddleReverse: 0
weight : 30
sideToneHz : 800
sideToneDb : 20
lfDelayMs : 0
keyDelayMs : 0
codec = WM8510
audio = BOTH_OPEN
duplex: New Audiocoding 108 (16 KHz)
phy = KSZ8041NL
-
This is getting more and more strange, hehe! Both your units seem to start up just fine...! I would have expected that they were endlessly resetting or something similar, but if the output stops after:
phy = KSZ8041NL
USB cable disconnected
then all seem normal!
What happens if you connect and disconnect the USB cable while running the terminal program? Du you get "USB cable disconnected" every time you disconnect it?
-
I get the "USB Unplugged" message ONLY when I plug the USB cable in. I also get the DNS error when I plug the USB cable in. I get no message when I unplug the USB cable. I plugged in the USB cable 3-4 times on each Control RRC and the output from COM1 is listed below.
Here are the messages from both my new Control RRC and the old Control RRC. Both Radio RRCs seem to be fine but I am now afraid to change any parameters because I don't want them to lock up as well.
==========================================
** 1285/1258 Bootloader V1.8 **
** Booting application **
==========================================
** Press capital x for xmodem apploader **
==========================================
setup load error
Company : Microbit
Product : 1258
Hardware : 6
Software : 2.35
Bootloader: 1.8
Compiler : 4.1.1 (WinARM)
Build : Mar 17 2011 11:06:54
ROM/RAM : 355948/54236
ethRAM : 2944 (max 3kB!)
USBRAM : 0
ResetSrc : b [3]
Uptime : 0
=========================
HW-device = 0
CW-pot = 300
Debug level = 0
Control panel = 1
Program mode = 4 - Yaesu, Kenwood, Elecraft
PID = 4
Setup length = 673
=========================
enable : 0
speedWpm : 0
iambic : 1
paddleReverse: 0
weight : 30
sideToneHz : 800
sideToneDb : 20
lfDelayMs : 0
keyDelayMs : 0
codec = WM8985
audio = BOTH_OPEN
duplex: New Audiocoding 102 (8 KHz)
phy = KSZ8041NL
USB cable disconnected
USB cable disconnected
### dns response
==========================================
** 1285/1258 Bootloader V1.5 **
** Booting application **
==========================================
** Press capital x for xmodem apploader **
==========================================
Using default profile
setup load error
Company : Microbit
Product : 1258
Hardware : 5
Software : 2.34
Bootloader: <= 1.7
Compiler : 4.1.1 (WinARM)
Build : Feb 14 2011 16:23:14
ROM/RAM : 341840/52964
ethRAM : 2944 (max 3kB!)
USBRAM : 0
ResetSrc : b [3]
Uptime : 0
=========================
HW-device = 0
CW-pot = 1023
Debug level = 0
Control panel = 1
Program mode = 4 - Yaesu, Kenwood, Elecraft
PID = 0
=========================
enable : 0
speedWpm : 0
iambic : 1
paddleReverse: 0
weight : 30
sideToneHz : 800
sideToneDb : 20
lfDelayMs : 0
keyDelayMs : 0
codec = WM8510
audio = BOTH_OPEN
duplex: New Audiocoding 102 (8 KHz)
phy = KSZ8041NL
USB cable disconnected
### dns response
USB cable disconnected
-
OK, about the "USB Unplugged": There is a problem with that, a problem that makes it do like you say, kind of "inverted" ;) But the point I had was that if you get that output at all when plug-in/plug-out the main firmware is executing in a normal manner.
The power led(green) will continue to flash after powering on until Ethernet is connected. You might also have to configure the IP Settings if they are wrong.
Came to think about that the red light/led should never be able to flash. Are you sure it actually does(or did) that?
Also, have you tried restarting your PC? I know that sometimes they stop recognizing new USB devices, especailly Win XP SP2 or older has that problem. Or have you tried using another PC?
Plugging in or out USB should not have anything to with getting DNS errors.
But frankly, this one is tough... You devices seem to run/start normally, yet you say that the don't work ok.
-
SUCCESS!!!
When the Ethernet cable was connected, the USB started working again. That logic seems like it is backwards. Shouldn't the USB connection be the connection that never fails? Once I got the USB working again, I changed the IP on my computer so that I could connect directly to the RRC (default 192.168.0.227, my network is 192.168.1.1). When I was connected, I changed to DHCP and connected the RRC to my network when I was able to adjust the other settings
To answer your questions:
1. I tried three different computers with the same result. OS were Win7, Win2000 and WinXP
2. The RED light flashes after doing the 20 second reset.
3. Re: DNS errors; I got the DNS message when plugging/unplugging the USB cable per the log I sent you. Maybe it was just coincidence?
Thanks for the suggestions. I think I can now move forward again.
-
Very odd indeed! Here USB works just fine without Ethernet connected. Did you notice/check which IP settings the RRC had when you connected Ethernet? Is this the fact for all(both) of the failing units?
USB is very very complicated, so it requires for the firmware to have exact timings and normal execution in order to work. If, for ex, some other part of the firmware becomes busy it might happen that USB stops working.
-
Both RRCs had the default IP because I had tried the 20 second reset to get things running again. For what it is worth, here is a message that was in one of the RRCs: "Data abort at 0x003b10c Called by 0x003bb34". Neither one would respond via the USB port until I connected the Ethernet plug. I honestly thought it would work without the Ethernet cable and never thought to try it until I got your previous message. Now that I know how to bring it back to life, I can recover if it ever happens again. The only thing I changed when this originally happened was to choose DHCP but that is probably a coincidence.
By the way, I loaded the new microRRC software and it works MUCH better than the older software. The audio stays connected constantly now whereas I had to experiment with many, many settings to just get audio to stay on for 20-30 seconds before dropping out. The CW interface still needs some work, I believe. The first character seems to run into the second character and the spacing does not seem to be the same between all characters. I'm sure this will get better over time and I will probably be using the RRC itself rather than the micro when I want to operate CW since I usually operate at 30+ wpm and the RRC works well for that purpose. The micro CW would only be used in emergencies.
Thanks Jan!
-
The Data abort-message is interesting, but I need to know the FW version in order to make something of it.
I too think/thought that USB should work without Ethernet, especially when default settings have been applied. Do you mean that now when you have them up and running USB works without Ethernet connected?
As for the RRC micro it would be great if you could post its issues in its forums, mostly because it's another person(Roland) who mainly works with it.
-
The Data abort message came from the RRC with 2.35 but not the one with 2.38.
Yes, USB works WITHOUT the Ethernet connection now. The green LED still blinks until the Ethernet is connected but I can configure the RRC with the Setup Application via USB. This is how I expected it to work originally. Much better now.
OK, I'll post my experience with micro in that forum, but basically, the largest problem has been fixed with the new software. The micro was unusable with the older software since the audio dropped out as the green bar constantly moved across the screen.
-
So while things are fresh in memory, is this what happened?
1/
You used Setup Manager to change from static IP to DHCP? Did you just check the DHCP box and then hit Save? Were Ethernet connected or not during that? Did you do it to more than one unit?
2/
You found the unit(s) in a state which not allowed further USB access?
3/
You tried short and long reset, but none worked?
4/
You connected a terminal and made some start-up output dumps?
5/
You connected Ethernet and suddenly USB started to work?
Any other detail you remember? I know I ask a lot, hehe, but I really would like to know what causes this very strange behaviour so that it might be possible to avoid it in the future, hopefully by some software modification.
-
The Data abort message came from the RRC with 2.35 but not the one with 2.38.
Looking into this I see that the data abort occurred somewhere in the TCP/IP stack=not in our firmware code as such. The conclusion I make from that and your problem with USB not working until you connected Ethernet is that somehow something got invalid/wrong with the network part of the firmware, making the firmware not executing normally and so the time critical USB code too suffered from this. Would surely have been valuable to either now what happened to the setup or being able to reproduce the error.
-
You have the facts correct in 1-5.
I believe the Ethernet was not connected when I changed to DHCP because I was moving these units to the remote site for testing at the time. The remote site has 192.168.0.1 as the main router address while my home network uses 192.168.1.1. The Control RRC will also be moving to another network where I don't know the setup so I wanted to set the control RRC to DHCP to allow it to adapt to whatever network it is used in. This seems to be the main cause of the lock up. When in the locked up state, USB access was not possible. I was only able to make progress after you mentioned I could get some status via the COM1 message. That allowed me to see what IP setting the control RRC was actually stuck upon. The I configured a PC to a static IP that was compatible with the IP inside the RRC. This allowed me to access the RRC via Ethernet so I could configure it again because the USB port was not working. One other thing that is probably insignificant is that I use Dynamic DNS.
It seems to me that there should be no possibility of the USB port becoming unusable. I got the same result on three different computers and operating systems (Win2000, WinXP and Win7) a so I don't think it could be USB port issue on my end.
I hope that helps in future firmware development.
-
Jan, one last thing. On my Win7 machine, I have Setup Version 1.9 loaded however, I don't see that version on your download page. My other two machine only have 1.8 loaded. I am not sure where I got 1.9 but could that be part of the problem? Was 1.9 a beta version that was posted for a short time and then removed?
-
You have the facts correct in 1-5.
I believe the Ethernet was not connected when I changed to DHCP because I was moving these units to the remote site for testing at the time. The remote site has 192.168.0.1 as the main router address while my home network uses 192.168.1.1. The Control RRC will also be moving to another network where I don't know the setup so I wanted to set the control RRC to DHCP to allow it to adapt to whatever network it is used in. This seems to be the main cause of the lock up. When in the locked up state, USB access was not possible. I was only able to make progress after you mentioned I could get some status via the COM1 message. That allowed me to see what IP setting the control RRC was actually stuck upon. The I configured a PC to a static IP that was compatible with the IP inside the RRC. This allowed me to access the RRC via Ethernet so I could configure it again because the USB port was not working. One other thing that is probably insignificant is that I use Dynamic DNS.
Hmm... But at which point in all this did the USB start working again? I thought it was when you connected Ethernet, but now I am not sure it was that "early".
It seems to me that there should be no possibility of the USB port becoming unusable. I got the same result on three different computers and operating systems (Win2000, WinXP and Win7) a so I don't think it could be USB port issue on my end.
I hope that helps in future firmware development.
USB is, as I wrote in a earlier post, very complicated. As such it needs all of the firmware running to work normally. Ideally it would always work, but in practice software will sometimes run into situations which cause problems like this. One can only take as much action as possible in order to prevent it from happening, but 100% fail safe is not possible, no matter how much one would wish it to be true :)
-
Jan, one last thing. On my Win7 machine, I have Setup Version 1.9 loaded however, I don't see that version on your download page. My other two machine only have 1.8 loaded. I am not sure where I got 1.9 but could that be part of the problem? Was 1.9 a beta version that was posted for a short time and then removed?
1.9 is available now for D/L. There should not have been a beta available before. A couple of persons might have got a 1.9-beta by email though.