HobbyPCB.com

Built by Hobbyist for Hobbyist!
It is currently Thu Apr 25, 2019 5:14 am

All times are UTC - 5 hours




Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Lockup Issue Behavior
PostPosted: Mon Mar 12, 2018 11:48 am 
Offline

Joined: Thu Feb 08, 2018 12:39 am
Posts: 15
I finished the new kit purchased a couple months ago and put it through it's paces this past weekend in the Wisconsin QSO party. Unfortunately there were a number of lockups of the display and sometimes a lockup with no power out. Here are the details of my setup and observations so far.

Setup:
- KX3 Radio
- Auto band change setup at 38,400 baud
- HobbyPCB supplied DB9 Breakout board
- Revision 3.0D firmware
- Hardware version G
- PTT mode
- QSK board installed
- CW and SSB modes
- Driven to about 50W output
- External SWR meter to monitor power

Symptoms:
- 11 lockups in an 8 hour QSO party contest
- Most lockups consist of the display locked up with -.- SWR and low PEP numbers. (But external power meter indicated full power)
- Some lockups with high SWR ~6.0 or more. (No power output on external SWR meter)
- Recovered each time by cycling power
- On one occasion the setup was idle in RX mode on 80 meters and heard a relay in the amp "click". The display was locked up and had to power cycle. Power output behavior in TX mode unknown.

Hypothesis:
- Running at 38,400 baud is causing the amp to go out to lunch....too fast. I would like to get a repeatable failure configuration and then decrease the baud rate to test. My PC software (NaP3) only supports 38,400 and no different, so I need to be a in situation that I don't run NaP3.

Has anyone experienced any of this behavior? I can't find any recent reports here in the forums.

I'll add more information as I learn more.

Scott


Last edited by kx9rt on Sun Mar 25, 2018 12:16 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Mar 12, 2018 3:48 pm 
Offline

Joined: Mon Jul 23, 2012 6:25 am
Posts: 1103
Hi Scott,

In the four years we have been shipping the Hardrock-50 this is the first time I have ever heard of the microprocessor freezing. I think the first thing I'd check is the 5V test point on the control board, maybe there's something wrong with the voltage supply. Otherwise I'd say send me the front panel and I'll replace the voltage regulator and the microprocessor.

73,
Jim WA2EUJ


Top
 Profile  
 
PostPosted: Mon Mar 12, 2018 4:00 pm 
Offline

Joined: Thu Feb 08, 2018 12:39 am
Posts: 15
Thank you Jim.

I'll test the voltage level.

I don't believe that I am using it outside of the intended use case. I am using many of the features at once with it streaming the frequency information, so I am probably pushing it pretty hard. I was initially thinking there could be internal RF during transmit that is getting into the processor radiated onto the ribbon cable or similar, but the hiccup during RX contradicts that. Unless there are multiple issues here. I was going to see if I could shorten any center pin coax connections so it is better shielded, but those connections are 1/4" or less exposed. I am trying to keep all of my descriptions to the facts.

One other observation is that the LCD screen does get sluggish at times to "repaint" the pixels going from TX to receive. It walks down the character blocks to update due to the transition from TX to RX states.


Top
 Profile  
 
PostPosted: Mon Mar 12, 2018 7:29 pm 
Offline

Joined: Thu Feb 08, 2018 12:39 am
Posts: 15
Not an awesome video, but I did capture one occurrence while connected to a dummy load.

https://youtu.be/etKHdYO3Yl4


Top
 Profile  
 
PostPosted: Mon Mar 12, 2018 10:26 pm 
Offline

Joined: Thu Feb 08, 2018 12:39 am
Posts: 15
The 5V regulator on the ICSP points is stable at 4.99V.

Maybe the occurrence in TX vs RX mode are two different problems. I wonder if there is RF in the enclosure getting onto the ribbon cable or power supply back to the control board. My RF out coax connections do have about 3/8" of exposed center conductor. Not sure how sensitive the micro is.

Anything else I should try?


Top
 Profile  
 
PostPosted: Tue Mar 13, 2018 5:35 am 
Offline

Joined: Mon Jul 23, 2012 6:25 am
Posts: 1103
OK, Thanks for the video. It's interesting that it still seems to key and unkey while it's locked up at least for a little while.

The only thing you might try is running the amp in COR mode and disconnecting the DB9.

The FW disables the COMMs during TX because the RF was causing erroneous characters to be received so that shouldn't be the issue. If your regulator is good I'm going to say that the PIC must be defective in some way.

Send me an email jim (at) hobbyPCB (dot) com and I'll send you shipping info. You can send me the front panel or the entire amp and I'll replace the microprocessor.

73,
Jim WA2EUJ


Top
 Profile  
 
PostPosted: Sun Mar 25, 2018 12:13 pm 
Offline

Joined: Thu Feb 08, 2018 12:39 am
Posts: 15
Just as a followup, I have been doing more testing re guarding the erroneous display data and lockups.

I tested it again for about 30 minutes using the same "contest" configuration with all the logging software running. I got it to fail within a couple minutes, and about 5 more times within 10 minutes.

I closed my logging programs and serial communications software.

Tested it for ~15 minutes with no failures.

Opened the PC software (LP Bridge) again and it failed within a minute or so a couple more times thereafter.

So from what I am seeing, it seems like the culprit is the LP-Bridge program that splits the comm ports so I can share the KX3 communications between programs. The application must be corrupting some bytes in the frame and guessing the PIC firmware is not always tolerant of the errors and causes the strange behavior of "UKN" band, clicking of relays, etc. Without any PC software running and transmitting dits 25WPM or greater, I can definitely see the amp display to slow down in it's updates, but it seems to be doing it's normal thing and catches up when slowing down or going to RX mode.

My conclusion that is LP-Bridge is not compatible with this amp. The data appears to be corrupted in the serial stream occasionally and the amp doesn't like it and often will not self recover. I am going to pursue using "COMOCOM" in place of LP-Bridge so I can continue using the serial port with this amp in combination with N1MM and NaP3.


Top
 Profile  
 
PostPosted: Fri Jan 18, 2019 11:09 am 
Offline

Joined: Thu Feb 08, 2018 12:39 am
Posts: 15
So I still experience frequent lockups of the Hardrock. I always have to do a power cycle in order to recover.

The previous posts in this thread are still relevant. But I think my theory of the LP Bridge program causing issues doesn't make sense. The frequency information in the serial stream I believe is an unsolicited (from PC) data stream of the current frequency, in other words only communications from the radio to the host PC logging program. That would mean there is no communications from LP Bridge to potentially cause data corruption.

One point to note is that all of my recent lockups are at 38400 baud.

What I have tried recently is to run the KX3 at slower speeds other than 38400 baud. I ran it at 4800 and 9600 baud with no lockups for a long time. (Without NaP3 running because it's not possible to run at slower speeds)

Unfortunately Logging and NaP3 Panadapter integration requires 38400 baud and is not adjustable in the software programs. So as soon as I go back to 38.4k, I can expect the amp to stop responding to rig communications within minutes of QSK CW transmit operation.

I do have an EE education and have embedded firmware experience. From observing the behavior and not knowing the details of what's going on inside the box, it feels like the amp microprocessor processing speed (interrupt handling) speed is being pressed against its limits when running at 38.4k.

I wonder how fault tolerant the amp firmware is if the datastream is corrupted or misses bytes in the KX3 frames? Is there any case where it would cause it be go into an unresponsive state?


Top
 Profile  
 
PostPosted: Sat Jan 19, 2019 3:06 pm 
Offline

Joined: Mon Jul 23, 2012 6:25 am
Posts: 1103
It could be that there a buffer overflow, but it should stop capturing characters if the buffer overflows. The HR50 has other commands that it responds to and I wonder if in the data that's flowing around it might be getting erroneous commands.

You could try putting an Arduino Nano on the serial line, listening for frequency commands and use a software serial port at 9600 baud to send just the frequency commands to the HR50. I can send you a Nano and the C code that pulls the frequency word out of the buffer.

Jim.


Top
 Profile  
 
PostPosted: Sat Jan 26, 2019 6:18 pm 
Offline

Joined: Thu Feb 08, 2018 12:39 am
Posts: 15
I missed your response. Yes, I have a nano and UNO here I could load the code onto.

Please help me understand your thought process. The nano would constantly stream out serial freq info frames to emulate the KX3?

I may want to sent it out at 38400 using a UART on the nano or UNO to replicate what I am seeing. I forget if one of those support the higher speed.

I did notice the display shows different info on lockups. Today it has a variety of "UKN" and also a static info screen.


Last edited by kx9rt on Sun Jan 27, 2019 11:53 am, edited 1 time in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next

All times are UTC - 5 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group