Topics

[BITxV6] BRICKED recovery help needed

Andy_501
 

In my vigor and enthusiasm to learn the arduino tools and Xloader I appear to have completely lost the display; all I get is a blank white screen and it does not enter the setup screen when I power it up with the tune button help. I believe the term that describes effect of my experimenting is "BRICKED" hihi

Prior to current state I had managed to receive CHU Canada time signal on 3330 KHz ; audio quality wasn't great due to BFO but definitely rx was finally working OK.  Had confirmed TX and RX were both functioning OK and moved onto code fam to be able to access software and software settings. Turned it all off to go to bed and this morning just a blank white screen on power up.

Hence my humble request for some assistance in de-bricking it !

So where might I find a link to download the latest V6 full software install and maybe a step by step description of how to install it properly again. Also Memory Manager and software settings manager software for V6

Thanks

Andy

On 2020-01-07 07:57, Evan Hand wrote:
Andy,

I have found that the BFO adjustment will make the uBitx sound terrible, tinny and full of high pops. Adjusted properly, the rigs (I have 3) all sound good.  Not great like my IC-7300, but good.

I would recommend trying the attached procedure, assuming that you have a device with internet and mic capability.  It works well, and will let you know visually that the rig's BFO is adjusted as best it can be.
https://www.hfsignals.com/index.php/bfo-tuning-aid/

NOTE: you will need a microphone connected and allow access to it to use the audio spectrum analyzer on the HFSignals web page. It works with my ipads and iphones if you do not have a pc/laptop with mic.

Original post from Farhan:
https://groups.io/g/BITX20/message/74079

73
Evan
AC9TU

Reed N
 

The white screen at power on is something I saw in my development too: https://groups.io/g/BITX20/topic/ubitxv6_bricked/69359467?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,40,69359467

Seems like the lack of power sequencing may mean that "slow" power supplies don't work well.


Reed

Andy_501
 

I have a dedicated 12 VDC @ 6 Amps supply for the uBITx transceiver with no other load on it.  The only thing I noticed in past sessions after connecting to laptop via USB port was that if I shut off the ON/OFF Vol control it stays powered up if the USB connection to laptop is live.

Everything was working fine as I indicated and I just powered it down for the night, as I had done many times before, and it did not start when I returned today. That is why I thought maybe the experimenting with the Xloader and or arduino uploading had somehow done a bad load just blanking all previous code. I don't have a h/w reset button on his one; I would need some sort of diagnostic program to run on laptop that could comm with USB port and do a reset via comm port I think but that would have to be a different program as well.

Something like this isn't great for teaching students in a course especially when cost is as high as it is.


On 2020-01-07 12:56, Reed N wrote:
The white screen at power on is something I saw in my development too: https://groups.io/g/BITX20/topic/ubitxv6_bricked/69359467?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,40,69359467

Seems like the lack of power sequencing may mean that "slow" power supplies don't work well.


Reed

Reed N
 

Hi Andy,

12V @ 6A is good, but doesn't actually indicate how "fast" your power supply is. Power supplies have ramp up times and response times that determine how "fast" they are.

I agree that not having an easy "reset" button is a potential issue. You could solder such a button on, and cut a hole in your case for a momentary push button, but for your target audience that may not be ideal?

I haven't put very much effort investigating the power sequencing yet, but it may be that there's a simple mod (either in software or hardware) that reliably prevents the "blank screen syndrome" in all cases. Definitely should be on the "to-do" list, though.


Reed

Jerry Gaffke
 

Andy,

If downloading firmware to the uBitx, not a bad idea to have a few spare Nano's handy:
    https://www.amazon.com/ELEGOO-Arduino-ATmega328P-Without-Compatible/dp/B0713XK923
Do buy a Nano without pins yet soldered in place as per that Elegoo product,
since to mount it into the socket provided on the Raduino, the Nano pins must be soldered on the 
top side of the Nano, not the bottom where normal people put them.

Having spare Nano's, you can practice downloading firmware without even touching the uBitx.
Once it is downloaded, can power everything off and with proper anti-static precautions,
move the new Nano into the socket on the Raduino to try the firmware out.
If the uBitx doesn't work, you can go back to the original Nano, see if that fixes it.

Having spare Nano's also means you can play with them on other projects.
They are very useful and fun.  You might get a few of the cheap 16x2 displays also.

Many have noticed that the uBitx receiver works with the uBitx power switch off
when a USB connection from a host computer to the Raduino is made. 
The power from the USB connection goes "backwards"
through the LM7805 regulator up into the main 12v rail of the uBitx.
Though that 12v rail only has something less than 5v on it, the receiver
behaves more or less normally.  It is possible that this could blow some 5v connection
on a Nano due to too heavy a current, though I'm not sure anybody has experienced this.
Might be best to add a 1n400x diode between the main uBItx 12v rail and the LM7805
regulator on the Raduino to prevent the backward flow of current from the USB connection. 

I don't know why your uBitx failed.
At $3, the Nano clones are of variable quality, perhaps it simply died for no particular reason.
With any luck, replacing the $3 Nano (after first burning appropriate firmware) will fix your uBitx.

Jerry, KE7ER


On Tue, Jan 7, 2020 at 11:28 AM, Andy_501 wrote:

I have a dedicated 12 VDC @ 6 Amps supply for the uBITx transceiver with no other load on it.  The only thing I noticed in past sessions after connecting to laptop via USB port was that if I shut off the ON/OFF Vol control it stays powered up if the USB connection to laptop is live.

Everything was working fine as I indicated and I just powered it down for the night, as I had done many times before, and it did not start when I returned today. That is why I thought maybe the experimenting with the Xloader and or arduino uploading had somehow done a bad load just blanking all previous code. I don't have a h/w reset button on his one; I would need some sort of diagnostic program to run on laptop that could comm with USB port and do a reset via comm port I think but that would have to be a different program as well.

Something like this isn't great for teaching students in a course especially when cost is as high as it is.

 

Wayne Leake
 

 I'll agree that having a spare Nano is a good idea. I bought 2 or 3 myself, pins not soldered that way I can experiment with the raduinos for other project ideas, I have a coupe of Unit's, and another bigger arduino that I bought to experiment with.
 BTW, I don't care for the green screen that come with the raduinos, so I changed one to a blue screen.
Pin for pin compatible, just had to solder
 Pins to the blue, and popped it in, so nice.
 Anyway, always a god idea to have spares when you experiment.

On Tue, Jan 7, 2020, 8:24 PM Jerry Gaffke via Groups.Io <jgaffke=yahoo.com@groups.io> wrote:
Andy,

If downloading firmware to the uBitx, not a bad idea to have a few spare Nano's handy:
    https://www.amazon.com/ELEGOO-Arduino-ATmega328P-Without-Compatible/dp/B0713XK923
Do buy a Nano without pins yet soldered in place as per that Elegoo product,
since to mount it into the socket provided on the Raduino, the Nano pins must be soldered on the 
top side of the Nano, not the bottom where normal people put them.

Having spare Nano's, you can practice downloading firmware without even touching the uBitx.
Once it is downloaded, can power everything off and with proper anti-static precautions,
move the new Nano into the socket on the Raduino to try the firmware out.
If the uBitx doesn't work, you can go back to the original Nano, see if that fixes it.

Having spare Nano's also means you can play with them on other projects.
They are very useful and fun.  You might get a few of the cheap 16x2 displays also.

Many have noticed that the uBitx receiver works with the uBitx power switch off
when a USB connection from a host computer to the Raduino is made. 
The power from the USB connection goes "backwards"
through the LM7805 regulator up into the main 12v rail of the uBitx.
Though that 12v rail only has something less than 5v on it, the receiver
behaves more or less normally.  It is possible that this could blow some 5v connection
on a Nano due to too heavy a current, though I'm not sure anybody has experienced this.
Might be best to add a 1n400x diode between the main uBItx 12v rail and the LM7805
regulator on the Raduino to prevent the backward flow of current from the USB connection. 

I don't know why your uBitx failed.
At $3, the Nano clones are of variable quality, perhaps it simply died for no particular reason.
With any luck, replacing the $3 Nano (after first burning appropriate firmware) will fix your uBitx.

Jerry, KE7ER

On Tue, Jan 7, 2020 at 11:28 AM, Andy_501 wrote:

I have a dedicated 12 VDC @ 6 Amps supply for the uBITx transceiver with no other load on it.  The only thing I noticed in past sessions after connecting to laptop via USB port was that if I shut off the ON/OFF Vol control it stays powered up if the USB connection to laptop is live.

Everything was working fine as I indicated and I just powered it down for the night, as I had done many times before, and it did not start when I returned today. That is why I thought maybe the experimenting with the Xloader and or arduino uploading had somehow done a bad load just blanking all previous code. I don't have a h/w reset button on his one; I would need some sort of diagnostic program to run on laptop that could comm with USB port and do a reset via comm port I think but that would have to be a different program as well.

Something like this isn't great for teaching students in a course especially when cost is as high as it is.

 

Andy_501
 

I will look into that as a future possibility if they give me a replacement unit due to this one failing in less than 30 days. If at the price you say they decide to OK me just discarding the faulty one instead of paying shipping to return it maybe I can tinker with it a bit rather than trying to learn on the replacement one. Doesn't bode well for recommending students buy a unit as part of a ham license upgrade course if these are that sketchy in reliability department.


On 2020-01-07 8:24 p.m., Jerry Gaffke via Groups.Io wrote:
Andy,

If downloading firmware to the uBitx, not a bad idea to have a few spare Nano's handy:
    https://www.amazon.com/ELEGOO-Arduino-ATmega328P-Without-Compatible/dp/B0713XK923
Do buy a Nano without pins yet soldered in place as per that Elegoo product,
since to mount it into the socket provided on the Raduino, the Nano pins must be soldered on the 
top side of the Nano, not the bottom where normal people put them.

Having spare Nano's, you can practice downloading firmware without even touching the uBitx.
Once it is downloaded, can power everything off and with proper anti-static precautions,
move the new Nano into the socket on the Raduino to try the firmware out.
If the uBitx doesn't work, you can go back to the original Nano, see if that fixes it.

Having spare Nano's also means you can play with them on other projects.
They are very useful and fun.  You might get a few of the cheap 16x2 displays also.

Many have noticed that the uBitx receiver works with the uBitx power switch off
when a USB connection from a host computer to the Raduino is made. 
The power from the USB connection goes "backwards"
through the LM7805 regulator up into the main 12v rail of the uBitx.
Though that 12v rail only has something less than 5v on it, the receiver
behaves more or less normally.  It is possible that this could blow some 5v connection
on a Nano due to too heavy a current, though I'm not sure anybody has experienced this.
Might be best to add a 1n400x diode between the main uBItx 12v rail and the LM7805
regulator on the Raduino to prevent the backward flow of current from the USB connection. 

I don't know why your uBitx failed.
At $3, the Nano clones are of variable quality, perhaps it simply died for no particular reason.
With any luck, replacing the $3 Nano (after first burning appropriate firmware) will fix your uBitx.

Jerry, KE7ER

On Tue, Jan 7, 2020 at 11:28 AM, Andy_501 wrote:

I have a dedicated 12 VDC @ 6 Amps supply for the uBITx transceiver with no other load on it.  The only thing I noticed in past sessions after connecting to laptop via USB port was that if I shut off the ON/OFF Vol control it stays powered up if the USB connection to laptop is live.

Everything was working fine as I indicated and I just powered it down for the night, as I had done many times before, and it did not start when I returned today. That is why I thought maybe the experimenting with the Xloader and or arduino uploading had somehow done a bad load just blanking all previous code. I don't have a h/w reset button on his one; I would need some sort of diagnostic program to run on laptop that could comm with USB port and do a reset via comm port I think but that would have to be a different program as well.

Something like this isn't great for teaching students in a course especially when cost is as high as it is.

 

Reed N
 

Andy,

Are you sure that your nano is broken? On my bench setup,  my screen comes up all white fairly often, but not every time. In fact, whenever I reset the nano, the screen works, so I don't think it's a broken nano at this point, but rather a power sequencing issue of some sort. If this is the case, then it may not matter how many nanos you try.


Reed

Andy_501
 

I am hoping they will just replace the whole daughter board combination of TFT display and nano board. If I upload Blink the status message says it transferred properly but on a power cycle restart the display comes up blank anyway. The USB comm portion seems like it is working with a valid transfer status message on the upload there is just no display. With no detailed tech info on programs or processes of diagnostic nature or configuration software to run from the laptop the only logical conclusion is that the display itself is what is defective It appears.

If I was familiar and experienced enough to be able to run some sort of other program modules like settings manager or memory manager or any other types I might be better able to come up with better half-split diagnosis. Like if I could load up a program and run it in say something like a single step or debug mode and get some feedback on statuses of what components were working and what wasn't that would be helpful. The only thing the Arduino GUI tool does is upload, which is apparently working to get hex code into memory but no associated GUI on the laptop to get any feedback.

On 2020-01-07 9:16 p.m., Reed N wrote:
Andy,

Are you sure that your nano is broken? On my bench setup,  my screen comes up all white fairly often, but not every time. In fact, whenever I reset the nano, the screen works, so I don't think it's a broken nano at this point, but rather a power sequencing issue of some sort. If this is the case, then it may not matter how many nanos you try.


Reed

Reed N
 

Hi Andy,

The default "Blink" sketch built into the Arduino IDE blinks the LED on pin 13 of the Arduino Nano, not the TFT screen. I'll take a stab and figuring out the white screen stuff tonight and will report back if I figure out a software-based fix.

In the mean time, since you can upload code, can you try uploading either Ashhar's master branch, or my pdq_gfx_update branch? In my experience, after uploading new code, the arduino resets and then the screen works.


Reed

Andy_501
 

The V6 hex code file is missing when I unzip it. It shows up if I download the V5 zip file and extract it.

via my shoephone

Sent from BlueMail

On Jan 7, 2020, at 21:47, Reed N <greenkid336600+groupsio@...> wrote:
Hi Andy,

The default "Blink" sketch built into the Arduino IDE blinks the LED on pin 13 of the Arduino Nano, not the TFT screen. I'll take a stab and figuring out the white screen stuff tonight and will report back if I figure out a software-based fix.

In the mean time, since you can upload code, can you try uploading either Ashhar's master branch, or my pdq_gfx_update branch? In my experience, after uploading new code, the arduino resets and then the screen works.


Reed

Jerry Gaffke
 

Andy,

As I understand it, the uBitx worked fine when it arrived.
You did some stuff and now it does not.

> I am hoping they will just replace the whole daughter board combination of TFT display and nano board. 

Good luck with that.

Jerry



On Tue, Jan 7, 2020 at 07:29 PM, Andy_501 wrote:

I am hoping they will just replace the whole daughter board combination of TFT display and nano board. If I upload Blink the status message says it transferred properly but on a power cycle restart the display comes up blank anyway. The USB comm portion seems like it is working with a valid transfer status message on the upload there is just no display. With no detailed tech info on programs or processes of diagnostic nature or configuration software to run from the laptop the only logical conclusion is that the display itself is what is defective It appears.

If I was familiar and experienced enough to be able to run some sort of other program modules like settings manager or memory manager or any other types I might be better able to come up with better half-split diagnosis. Like if I could load up a program and run it in say something like a single step or debug mode and get some feedback on statuses of what components were working and what wasn't that would be helpful. The only thing the Arduino GUI tool does is upload, which is apparently working to get hex code into memory but no associated GUI on the laptop to get any feedback.

Reed N
 

Hi Andy,

I'm not sure what specific zip file you're referring to, but it may be that the zip file just has the source code, and you would have to use the Arduino IDE in order to compile and load it onto your nano.

I've attached a .hex file that I just built from my pdq_gfx_update branch. Maybe you can load it?


Reed

Andy_501
 

No I followed the instructions I gleaned from the group posts and the scant mfr's documentation and was kind of learning as I went. It was working at the end of the evening when I powered it down so I could go to bed for the night. I turned it on the next morning to continue familiarizing myself but when power was applied it simply came up a blank white screen with no signal or RF white noise coming from the speaker. I powered it down and restarted it holding the TUNE button at the same time but everything just stayed white and blank so it would not enter the initial start setup routines either.

When I first received it, the initial setup of the ref freq would not adjust to exactly 10 MHz but instead had to settle on 10.5 MHz; the Zero Beat Freq adjustment also did not set up as it was supposed to; I had to ballpark it at 11.055 MHz then rock the tuning control above and below until I could hear a reasonable audio sound quality of RF white noise rather than a clearly defined zero beat on a signal. In general the transceiver functions were seemingly working but the audio sound quality has always been tinny /water barrel like/ or Donald Ducky sounding. I was able to receive the Canadian time signal on 3330 KHz but the audio was not crisp and clear. I was unable to get into the software to adjust or check software parameter settings; partly because I had not progressed that far before it failed and partly because Nobody answered in any group posts with links , tutorials or comments about specifically running those manager type programs.

In addition to being an advanced amateur, I am a retired Electronics Engineering Technologist (35 yrs) with certification in the Pace electronic repair course; so I know enough not to go poking around in a willy nilly fashion.

cheers & 73 de VE4PER

Andy



On 2020-01-07 10:21 p.m., Jerry Gaffke via Groups.Io wrote:
Andy,

As I understand it, the uBitx worked fine when it arrived.
You did some stuff and now it does not.

> I am hoping they will just replace the whole daughter board combination of TFT display and nano board. 

Good luck with that.

Jerry



On Tue, Jan 7, 2020 at 07:29 PM, Andy_501 wrote:

I am hoping they will just replace the whole daughter board combination of TFT display and nano board. If I upload Blink the status message says it transferred properly but on a power cycle restart the display comes up blank anyway. The USB comm portion seems like it is working with a valid transfer status message on the upload there is just no display. With no detailed tech info on programs or processes of diagnostic nature or configuration software to run from the laptop the only logical conclusion is that the display itself is what is defective It appears.

If I was familiar and experienced enough to be able to run some sort of other program modules like settings manager or memory manager or any other types I might be better able to come up with better half-split diagnosis. Like if I could load up a program and run it in say something like a single step or debug mode and get some feedback on statuses of what components were working and what wasn't that would be helpful. The only thing the Arduino GUI tool does is upload, which is apparently working to get hex code into memory but no associated GUI on the laptop to get any feedback.

Andy_501
 

OK Reed Thanks it is getting late here now I will give it a look tomorrow.

On 2020-01-07 10:52 p.m., Reed N wrote:
Hi Andy,

I'm not sure what specific zip file you're referring to, but it may be that the zip file just has the source code, and you would have to use the Arduino IDE in order to compile and load it onto your nano.

I've attached a .hex file that I just built from my pdq_gfx_update branch. Maybe you can load it?


Reed

Reed N
 

Hey Andy,

I hope you got a good night's rest. I think I have a fix! The attached hex file for me has NOT white screened EVER in my testing. Prior to this commit (f1ea1fd081d128895f336d0ca16de6246a422f2f) I'd get a successful screen render once every blue moon. Now, I have yet to get a failed screen boot. Hopefully it solves the problem on your end too.


Reed

Reed N
 

Andy,

Did you have a chance to try the hex file I sent? If so, did the update fix the white screen issue you were seeing?


Reed

mm0bef@...
 

I bought a screen for my v5 but had errors compiling the origonal v6 code. It just showed white screen on switch on so ill try your hex later tonight to see if that helps. 

Thanks and good work

73
MM0BEF____Brian

Andy_501
 

Hi Reed,

I finally managed to get your arduino hex file uploaded into the nano and the display back to what appears to be normally visible. The 17M selection is working properly, albeit sluggishly,  with this version also.

I managed to get the test menu to work also somewhat sluggishly.

1. I am unable to set the ref FREQ to 10 000 ; the closest is 10500

2. The zero beat adjustment adjusts above and below but does not produce a zero beat state. The receiver works and I am able to hear WWV on  2.5 MHz and CHU Canada on 3.330 MHz The zero beat adjustment allows me to hear the signals and voice components/announcements but continuously has approx a 500 Hz tone superimposed on the time signals which appears as though it might be due to the freq setting from step 1. not working as text instructions state it to be set.

3. I am able to select Hand Key setting and in CW mode it outputs the full 10 Watts on 80 M band on key down; however if I key a test transmission at about 10-12 wpm with the hand key the lag between key down and RF output is serious problem (no setting of key delay helps improve). It is so bad I would not be able to use it for CW operation. I plug the hand key into the Mic jack and have the key control the PTT; in CW mode it generates CW sidetone signal but hand key does not work when plugged into the J4 Morse Jack at all.

4. Changing modes using the color display buttons and a stylus works but it also exhibits serious delays and even sometimes requires selecting the new band a second or third time to finally get it to change. It is almost as if the morse code hand keying and TFT screen servicing routines get hung up in an idle code loop delay of some sort that makes the overall operation seem sluggish or seriously lagged or unresponsive/insensitive.

But on the plus side The BRICKED white screen appears to have been cleared up; The only other possibility is that the TFT/nano daughterboard pair has a problem that is creating the sluggish performance; and HFSignals promised replacement has not been sent to me and thus I am unable to compare it with a supposed new one. They promised on two separate emails to send me a replacement however have not so far lived up to that promise.

Any suggestions now Reed?

Thanks for the hex file download

Andy



On 2020-01-08 1:16 a.m., Reed N wrote:
Hey Andy,

I hope you got a good night's rest. I think I have a fix! The attached hex file for me has NOT white screened EVER in my testing. Prior to this commit (f1ea1fd081d128895f336d0ca16de6246a422f2f) I'd get a successful screen render once every blue moon. Now, I have yet to get a failed screen boot. Hopefully it solves the problem on your end too.


Reed

Reed N
 

Hi Andy,

I'm glad to hear it fixed your white screen problem. I've made some changes to the code since then, and can get you an updated binary if you can't compile yourself, though I don't know that it will solve any of your specific issues.

1) the stock code changed the LO in steps of 875Hz, which is ~1ppm, since the PLL target is 875MHz. I know that my setup is also slightly off of zerobeat, but I figured "close enough" and left the step size as is. I could make the step smaller, but then you'd have to do a lot more turning. I'm hoping to get a "momentum" thing built in to the encoder, so if I get that in place, I can drop all the step sizes without sacrificing speed of tuning.

2) This is quite likely due to the step size of the cal

3) A couple other threads have mentioned issues with keying, so you're not alone. I haven't looked into improving those functions at all, so I can't comment as to how easy or hard a fix might be.

4) I haven't experienced much, if any, lag on my touch inputs recently, but I know that if it's not well calibrated, it will drop inputs because it will think you're pressing where no buttons are. If you haven't already, remove the protective film that shipped covering the screen. Try recalibrating the touch screen using the stylus, even if you plan on operating using your fingers, and see if that helps.


Reed