¿ªÔÆÌåÓý

Date

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


Re: Did I break my V6? #ubitx

 

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


Re: audio to audio amp

 

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



Re: compile error

 

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

Jack, W8TEE
 

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:



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?


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:

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


Re: ubitx #v6 Screen Speed Mod, and interrupt driven encoder wheel mod #v6

 

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


Re: ubitx #v6 Screen Speed Mod, and interrupt driven encoder wheel mod #v6

 

So Mark, just to be clear, this code will work with the existing stock encoder also?

Joel
N6ALT


Re: ubitx #v6 Screen Speed Mod, and interrupt driven encoder wheel mod #v6

 

¿ªÔÆÌåÓý

Here's my fork of your code with my changes applied:

In whole, the goal was to improve the responsiveness of the UI, and I think the combination of your graphics work and my encoder work, it is top notch right now.

Known problems:
  • My code no longer waits 100ms or 200ms or whatever it was to count the number of encoder ticks, there-by greatly improving the responsiveness.? The problem is that we almost always only count a single tick, maybe two or three if you really spin the knob.? So the acceleration that Farhan built in doesn't do anything. The knob is entirely linear. I've got some ideas to measure the tick rate in doTuning() instead, but haven't implemented them.
Right now, this is a fork from your code (Reed's pdq_gfx_update branch) because I wanted to build it on top of yours.? When Farhan pulls yours into the master branch, I'll re-fork, cherry-pick my commits, and submit a PR.? In the mean time, I'd love feedback on my changes.

73 de KR6ZY
-Mark

On 1/7/20 6:58 PM, Reed N wrote:

Hi Mark,

I'm reluctant to accept PRs into the pdq_gfx_update branch until Ashhar gets it merged into his master, since it's usually best practice to keep each PR focused on a single change, but I'd be very interested in seeing your interrupt-based encoder branch, and definitely would recommend you create a PR for it to be merged into Ashhar's master after the pdq_gfx_update is merged in.


Reed


Re: Relative Power indication on Nextion display

 

Hi Mike, I am building now a SWR Bridge from Kits and Parts to display the output power on LCD and I have the same issue, on RX voltage on A7 is indicated on my 16x2 as expected, on TX there is no indication regardless of the potential of A7. I am looking into the code but I am a little overwhelmed, but I don't loose hope just yet. Maybe someone could help us. Thank you!


Re: Relative Power indication on Nextion display

 

Is anyone using the Nextion meter for relative power and not just S-meter function? ?I¡¯m not seeing a place in the code to disable it during transmit, but even with voltage on A7 not getting any deflection.

Thank you.

Mike