Brian, to get mine to work I used 1k2 series resistors on all the data lines connected to the TFT and reduced the VCC to the TFT by connecting the 5V through a couple of series Si diodes. It would appear that some of these SPI TFTs work happily with a VCC of 5V and TTl data levels while others do not.
|
I just let the laptops inbuilt mic do the work from the speaker. I connect a normal audio cable from laptop to the mic and let the usb cable do the ptt. The ubitx cables were designed to work without any special connectors. - f
On Sun 12 Jan, 2020, 12:33 PM Mike KD7ZPC, < memcki@...> wrote: Hi Paul,
I ran in to issues with the laptop's mic-in setup. The audio plug on the laptop tries to be too clever, and functions as either a mic or a headphone jack, and there's only the one. I had a USB soundcard dongle from a Christmas Light LED project, but the mic-in on that one was really a headset jack. That would short out the mic cord from the V6 so that it would go into transmit mode as soon as I plugged it in. I finally had to order an even cheaper sound dongle so that it had a simple mic-in and phono-out pair of jacks (If it's more than $8.00 on Amazon, it's probably too fancy. The one that works for me was $6 or $7. :-) ). I connected the V6 via USB, and the mic and phone from the V6 to the simple dongle, and then configured WSJT-X to use FT-817 CAT control and the correct audio in and out, and away it went.
I do seem to have to try a couple of times to get the software to connect to the com port each time after I've had the radio disconnected and the laptop in sleep mode, but that's been mostly just an irritation so far. I've been mainly operating WSPR so far but the set-up is the same up to the point you choose WSPR over FT8. You can generally find me running on 40M in the evenings.
Don, KM4UDX, who is pretty active on this group has been a really big help.?
Cheers!
~Mike W7SQL ex KD7ZPC
|
Vic
He didn't say he was using strait key or paddle, but it seems he is describing normal behavior if the op doesn't compensate in straight key mode. I have made hundreds of cw contacts using my v4, but its different than the best qsk rigs with electronic TR like the qcx or k2 etc. I even have to adjust with my yaesu that uses a relay. There is a cw delay setting on v4 stock firmware, I found its default value works best for me.
73 curt
|
Thanks...hope you enjoy it!
Jack, W8TEE
On Saturday, January 11, 2020, 10:54:57 PM EST, Bob Bennett via Groups.Io <bobsmacbox@...> wrote:
Thanks to all. I was able to update the ubitx with my Mac. I changed the usb connection from the mac and connected it direct to the Raduino card.
Again, thanks to all.
Now to work on the filters to see if I can get rid of the hash noise
And, Jack, your book came today ;-)
--
Bob
NZ2Z
-- Jack, W8TEE
|
I do not have a V6, but a friend who is not on the group has and is having some issues with CW operation. This is a quote from his email to me. Have others ruin into this and is there a fix? I don't see this issue on my V4:
The V6 sends a short dot, maybe a 1/4 dot, when keyed; then there is a short space, maybe a 1/4 space; then it sends good code until you stop sending; then there is a short space, maybe a 1/8 space; then, finally, a short dot, maybe a 1/8 dot.? I can see it on my spectrogram.? (Maybe I can figure a way to capture the spectrogram and send it to you.)? So, it looks like the first character is being truncated, but that is really not the case; it's sending extra characters at the start and end of sending.? After you get passed the initial keying it sends very good code..? The extra character at the end of a series of characters can be lived with; however the extra character at the being makes is very difficult.? It's like in the army using the BC610 transmitter:? you had to turn the transmitter on and then send -- a sort of missing push to talk deal? It's like that with the V6 except that when you turn the V6 on it sends the extra small dot character..? It does this whether the first character begins with a dot such as "R" or a dash such as "Q".
?
This must be fixed before the thing can be used in any meaningful way on CW.
|
Re: ubitx #v6 Screen Speed Mod, and interrupt driven encoder wheel mod
#v6
Hi Mark,
The interrupts are very responsive, which is great. Definitely worth merging immediately after the PDQ branch, and cleaning up the code a bit more later. I'd recommend that you give your changes a new branch name (e.g. "git checkout -b interrupt-encoder" - no need for cherry-picking) to avoid confusion.
Reed
|
Hi Paul,
I ran in to issues with the laptop's mic-in setup. The audio plug on the laptop tries to be too clever, and functions as either a mic or a headphone jack, and there's only the one. I had a USB soundcard dongle from a Christmas Light LED project, but the mic-in on that one was really a headset jack. That would short out the mic cord from the V6 so that it would go into transmit mode as soon as I plugged it in. I finally had to order an even cheaper sound dongle so that it had a simple mic-in and phono-out pair of jacks (If it's more than $8.00 on Amazon, it's probably too fancy. The one that works for me was $6 or $7. :-) ). I connected the V6 via USB, and the mic and phone from the V6 to the simple dongle, and then configured WSJT-X to use FT-817 CAT control and the correct audio in and out, and away it went.
I do seem to have to try a couple of times to get the software to connect to the com port each time after I've had the radio disconnected and the laptop in sleep mode, but that's been mostly just an irritation so far. I've been mainly operating WSPR so far but the set-up is the same up to the point you choose WSPR over FT8. You can generally find me running on 40M in the evenings.
Don, KM4UDX, who is pretty active on this group has been a really big help.?
Cheers!
~Mike W7SQL ex KD7ZPC
|
Re: ubitx #v6 Screen Speed Mod
#v6
Thanks Reed.
I also have no real way of testing it right now.? Realize that a post isn't the best way to manage software changes too.
|
Re: ubitx #v6 Screen Speed Mod
#v6
Hi Gary,
I tried to minimize the changes in my branch, so the frequency format function is probably from Ashhar's original software. There's an issue for it posted here:
I'd recommend you create a pull request for the change you're proposing, since that's the normal way to do this sort of thing, or barring that, you could post the code in that issue's comment thread. Posting it here is better than nothing, but it's also a) not specific to the screen speed branch I made, and b) likely to get lost in the email threads.
Reed
|
Gary
placement of this audio amplifier depends whether you only want it to drive the speaker, or also feed the headphone.
Sunil's case has a beakout board to host the audio output. I am in process of integrating a Nescaf audio filter that ends with a lm386 stage. I plan to intercept the audio where it leaves the main board, but I haven't got that far yet. Caution is to keep added gain low, but added output power should help a v4 like mine.
Curt
|
Thanks to all. I was able to update the ubitx with my Mac. I changed the usb connection from the mac and connected it direct to the Raduino card.
Again, thanks to all.
Now to work on the filters to see if I can get rid of the hash noise
And, Jack, your book came today ;-)
--
Bob
NZ2Z
|
Re: ubitx #v6 Screen Speed Mod
#v6
So, whose code is the function?void formatFreq() in the V6? Recognition to Jack for code size reduction by removal of? sprintf, but where is the correct place to discuss a potential improvement? IMO, it's also posting 'simple stuff' to this group so active folks can grab it and have a look too.? I'm not a real c coder, but I have a lot of code that I know has holes when used outside the intended purpose. Much as formatFreq() below 1 MHz. The real coders are working on bigger issues, but since I was thinking about it: I scratched out a change that addresses the 'feature' / comments about tuning below 1 MHz. (which is outside of the TX operating range, so IMO nothing to complain about) Keeping in the spirit, it should actually use less program space.? I don't have a V6 / TFT to test.? It's really just a replacement of an if/else with a for loop.? So yes, it will be slightly slower. My version will have a 'bug' below 100 Hz.? So the ULF guys will still complain.? This is just hobby stuff for me.? Sometimes longer to write a post than to actually do work.
void formatFreq(long f, char *buff) {
? // tks Jack Purdum W8TEE
? // replaced fsprint commmands by str commands for code size reduction
? // AG5TX
? // resolved issue with format below 1 MHz, there is an issue below 100 Hz but trying to keep code size small and simple
? unsigned int g = strlen(b);
?
? memset(buff, 0, 10);??
? memset(b, 0, sizeof(b)); // b is a global
?
? ultoa(f, b, DEC);
?
? for (unsigned int i = g; i < 8 ; i++){
? ? ?strcat(buff, " ");
? }
?
? strncat(buff, b, g-3);
? strcat(buff, ".");
? strncat(buff, &b[g-3], 2); // set last arg to 2 or 3 for how many digits you want right of the decimal point.
}
|
Re: ubitx #v6 Screen Speed Mod, and interrupt driven encoder wheel mod
#v6
This is a classic example of polling versus interrupts. I've used this example here before:
Suppose you're setting up a fire alarm system for the Empire State building. There are 100 sensors per floor. The controller in the basement visits each sensor and reads whether there is a fire (1) or no fire (0). The sensor reading is reported back to the basement after each sensor read. The "round trip" takes 1 second to report from a sensor. When sensor #100 reports, the code reads sensor number 1 on the second floor. This process repeats until all sensors for all 108 floors have been read. The process then starts all over again on the first floor. This is a polling alarm system.
Now suppose your luck is such that sensor #100 on the first floor burst into flame just as you read sensor #1 on the second floor. By the time you re-read sensor #100 on the first floor again, the fire has a 3 hour head start. You'd be surprised how miffed people get when they have to wade through 10 floors of fire on the way to lunch.
Now suppose instead that each sensor has the ability to send a message to the basement the instant it detects a fire. The fire would be known in 1 second. This is how interrupts work. Except for all but the most trivial programs, interrupts will always yield a more responsive system.
When writing ISR's, just make sure that 1) you don't use any functions that themselves use interrupts (no delay() or Serial.print()'s), 2) keep the ISR as short as possible, and 3) declare any globals used in the IRS with the volatile type specifier.
Jack, W8TEE
On Saturday, January 11, 2020, 5:02:40 PM EST, Joel Caulkins/N6ALT <caulktel@...> wrote:
Thanks for explaining your changes Mark, it makes sense now and explains why the display flashes every time the digits change also. All in all, it's working pretty good now.
Joel
N6ALT
-- Jack, W8TEE
|
Re: #v5 Audio, Ground?
#v5
Thanks Alan, I figured that from another post, unfortunately, I reduced the solders in that area, placed tape over the chassis screw, still have the issue when the board touches the posts. So I replaced them with plastic posts, that solved the lost audio issue but now I have super loud noise, hissing that reduces a bit once I get a signal, but still makes it hard to operate. Will keep looking :( A
On Sat, Jan 11, 2020 at 8:00 PM < nx4j@...> wrote: I just completed putting a V3 into an amatuerradiokits case with Nextion 2.8 front panel and had this same issue. The problem turned to be the 3 pins that support the volume control connection on the aux board were shorting on the metal left post that supports the front stand on the bottom of the case. To resolve this I located a short little plastic cap and placed over the post which eliminated the short. This is not an issue with the 2 line lcd display as the aux board mounts much higher on the front panel.
Alan
NX4J
|
Re: #v5 Audio, Ground?
#v5
I just completed putting a V3 into an amatuerradiokits case with Nextion 2.8 front panel and had this same issue. The problem turned to be the 3 pins that support the volume control connection on the aux board were shorting on the metal left post that supports the front stand on the bottom of the case. To resolve this I located a short little plastic cap and placed over the post which eliminated the short. This is not an issue with the 2 line lcd display as the aux board mounts much higher on the front panel.
Alan
NX4J
|
Re: Ubitx V6 Nextion 2.8" Display Modification
And here is the pic: 
toggle quoted message
Show quoted text
On Jan 11, 2020, at 6:19 PM, bill richardson via Groups.Io <ng1p.bill@...> wrote:
? I did this mod to my V6 and with the Nextion display my current draw dropped from 350ma to 250ma (TFT draws 100ma more!) also I wired a on off switch so I could remove 5v from the display. With the display off I’m seeing just 150ma. I will also add the 5v regulator is running much cooler. I like the option of shutting off the display to save on battery life.
One other thing I did differently was instead of using a angled display plug I just simply solder to the back side of the board (keeps the wires out of the way) I also drilled the Nextion mounting holes a little wider so all 4 mounting screws are in place on the front of the display.
73 thanks for the great mod. Bill ng1p? On Jan 6, 2020, at 5:29 PM, bill richardson via Groups.Io <ng1p.bill@...> wrote:
? Sounds excellent. I may do what you did. I’m looking at ways to save on current and I really like the CDC code. If you remove the 5v from the display I assume the radio will still operate? With your hookup it would be easy to add a switch. On Jan 6, 2020, at 4:50 PM, wb2cba@... wrote:
? Hi Bill,
Before the mod I checked each display’s datasheet to compare power consumption and ?both draws around 60 to 65 ma of current.
I didn’t actually measure the current draw on the raduino board 7805 regulator but it does feel hot with both displays, stock and nextion. May be it is a good idea to swap the heatsink with a notch bigger one.
I used the rig continously for almost 3 hours yesterday for qso’s and nothing smoked up so I think it’s surviving the heat ?:)
Barb, WB2CBA
|
Re: Ubitx V6 Nextion 2.8" Display Modification
I did this mod to my V6 and with the Nextion display my current draw dropped from 350ma to 250ma (TFT draws 100ma more!) also I wired a on off switch so I could remove 5v from the display. With the display off I’m seeing just 150ma. I will also add the 5v regulator is running much cooler. I like the option of shutting off the display to save on battery life.
One other thing I did differently was instead of using a angled display plug I just simply solder to the back side of the board (keeps the wires out of the way) I also drilled the Nextion mounting holes a little wider so all 4 mounting screws are in place on the front of the display.
73 thanks for the great mod. Bill ng1p?
toggle quoted message
Show quoted text
On Jan 6, 2020, at 5:29 PM, bill richardson via Groups.Io <ng1p.bill@...> wrote:
? Sounds excellent. I may do what you did. I’m looking at ways to save on current and I really like the CDC code. If you remove the 5v from the display I assume the radio will still operate? With your hookup it would be easy to add a switch. On Jan 6, 2020, at 4:50 PM, wb2cba@... wrote:
? Hi Bill,
Before the mod I checked each display’s datasheet to compare power consumption and ?both draws around 60 to 65 ma of current.
I didn’t actually measure the current draw on the raduino board 7805 regulator but it does feel hot with both displays, stock and nextion. May be it is a good idea to swap the heatsink with a notch bigger one.
I used the rig continously for almost 3 hours yesterday for qso’s and nothing smoked up so I think it’s surviving the heat ?:)
Barb, WB2CBA
|
Re: ubitx #v6 Screen Speed Mod, and interrupt driven encoder wheel mod
#v6
Hi Smitty.
Just tried your version, much nicer to tune.
Philip G7JUR
|
Re: ubitx #v6 Screen Speed Mod, and interrupt driven encoder wheel mod
#v6
Thanks for explaining your changes Mark, it makes sense now and explains why the display flashes every time the digits change also. All in all, it's working pretty good now.
Joel
N6ALT
|
Re: ubitx #v6 Screen Speed Mod, and interrupt driven encoder wheel mod
#v6
I'm not entirely sure which you meant, so let me answer the question
you MIGHT have been asking in case others are similarly confused.?
:-)
Does it work with the existing encoder wheel hardware?? Yes.? No
hardware mods are required.? This is a software-only mod that
improves the responsiveness of the encoder wheel.? Instead of the
code saying "I want to know what the user is doing with the encoder,
let me sit here and spend 200ms watching the encoder wheel to see
whether it's turning, and not doing anything else."?? Instead, it
uses hardware interrupts.? Every time the state of one of the pins
changes, the program pauses and runs my function instead, called an
Interrupt Service Routine, or ISR.? All the ISR does is look at the
current state of the pins and compares it to the previous state of
the pins, figures out which way you turned the knob, and either adds
1 or subtracts 1 from a counter.? Then, when the program says
"what's the encoder doing?" instead of waiting around 200ms to
count, it just returns the existing counter and sets it to zero.??
So the program no longer has that 200ms pause every time it wants to
see what the encoder is doing.
Does it work on the stock software, or does it require Reed's
display mods?? It'll work on the stock software, but the merge
requires a bit of work.? Reed's changes changed some code my code
also changed, so I had to manually merge them.? It's not a HARD
merge, but it's also not automatic.
If someone wants a branch that uses this code against Farhan's stock
code, I can produce that too.
-Mark
On 1/11/20 1:05 PM, Joel Caulkins/N6ALT
wrote:
toggle quoted message
Show quoted text
Forget that last question, I loaded up Marks's code and the
encoder works great. Thanks to those who know how to code we are
getting closer everyday to a usable V6 UBITX.
Joel
N6ALT
|
Vic WA4THR
Bob Bennett
Joel Caulkins/N6ALT
Smitty, N6MTS