¿ªÔÆÌåÓý

Date

Re: New file uploaded to [email protected]

 

Hi all.? A belated Happy New Year.

There's been quite a few requests for help with the TFT for the V6, the ones available in the wild are hit and miss.? I've now got 5 of the 2.8 TFT obtained from 3 vendors over the last year or so.? They seem to be the worst thing out at raising ones blood pressure with frustration trying to get them to operate correctly.? Of the original 3 only 2 will ok correctly with the Blue Pill yet all of them are fine with a Teensy 3.2.

I have also been watching with interest progress of the code for the V5 and then the V6 with a view to upgrading my early V3, more frustration with both types of display.? The TFT would be a great addition, so that's the way I'm going,? hence ordering some new versions. I've spent a troubled few days trying to coax one of the TFT's no go, the code assembles loads correctly,the display is wired up ok, I know it functions with the Blue Pill so back to basics.

I tested the TFT with a level converter, easy to do and magically it functions. So her's my thoughts to share with others it may help. You can find the schematic here??/g/BITX20/files/V6%20TFT%20Adapter

This is intended hopefully to assist with the problems encountered when trying to obtain a suitable TFT to use with the Ubitx V6 code.? Very many of these displays available from China are advertised as 3.3/5v (operation ?), they will run with either a? 3.3 or 5v supply but will only work with 3.3v logic signals. When wired as in V6, and running the code, the display will show only a blank white screen.

?

The idea is that this should act as an interface directly between the lead from the raduino and the actual display in use, no messing about with your Raduino.

Hope this is helpful to someone.

David S


New file uploaded to [email protected]

[email protected] Notification
 

Hello,

This email message is a notification to let you know that the following files have been uploaded to the Files area of the [email protected] group.

Uploaded By: David S <dsatn04@...>

Cheers,
The Groups.io Team


Re: uBitX on CW #v6

 

He has the same results either using a keyer or a straight key, although it isn't clear to me whether it is happening with the internal keyer and a set of paddles as opposed to an external keyer. He describes it as having to "turn it on" by sending a dit or a dah (they result in the same truncated did on the output) and then when the relay is engaged sending is normal. it sounds like it is sending something as the transmit relay engages, and again when it disengages, so even if he toggled the relay on before sending, he would get a burst of RF just like he does when it times out at the end.? I'll suggest he play with the CW delay, but it seems to output that RF whenever it times out, anyway.

He is a long-time CW op and currently an NCS on a CW traffic net.

=Vic=


Re: New uBITX Ver. 6 Assembled Today

 

¿ªÔÆÌåÓý

After doing some tests and working with a local Elmer (thanks Bill) we have confirmed the v6 is transmitting we noticed the audio was weak and muffled so I¡¯m going to upgrade the mic and work on improving the antenna.
Thanks for all the help and advice.

73
Mick VA3EPM

On Jan 10, 2020, at 6:05 PM, Ted via Groups.Io <k3rta@...> wrote:

?
Well, there is this........? an end-fed multibrand using a trap.

http://www.infotechcomms.net/downloads/Multi_band_EFHW.pdf


Re: compile error

Jack, W8TEE
 

What compiler are you using?\

Jack, W8TEE

On Sunday, January 12, 2020, 10:33:37 AM EST, Bob Bennett via Groups.Io <bobsmacbox@...> wrote:


I use the Raspberry Pi as one of my main computers for projects. It¡¯s my mini-desktop
--
Bob
NZ2Z

--
Jack, W8TEE


Re: compile error

 

I use the Raspberry Pi as one of my main computers for projects. It¡¯s my mini-desktop
--
Bob
NZ2Z


Re: compile error

GM4CID
 

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.


Re: Did I break my V6? #ubitx

 

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


Re: uBitX on CW #v6

 

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


Re: compile error

Jack, W8TEE
 

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


uBitX on CW #v6

 

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


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