Keyboard Shortcuts
Likes
- BITX20
- Messages
Search
Re: Ubitx v6.1 cat control
On Thu, Jul 2, 2020 at 06:36 AM, Dean Souleles wrote:
Barry -? With other radios ( I presume the ubitx is no different ) it is VERY discouraged to directly connect audio ports do to the possibility of a ground loop issue. It is best to use isolating transformers for this. There is one kit I have purchased in the past that was inexpensive. (I cannot find the purchase right now) I would also go so far to say its recommended to have isolation in the usb connection as well.? I'm not saying this method won't work, it is just risking causing issues with your computer or radio or both. I found a pack of 10 audio xfmrs for ~$11 on amazon so it wouldn't be difficult to create your own.? 73 |
Re: Problems with adding Nextion Display and CEC Software
I'm pretty sure that is the same version of Xloader that I was already using. The file dates are different but the file sizes appear the same. Tried it anyway but with the same results. Both say version 1.0 What puzzles me the most at this point is the fact that I swap out the nano with the one that had Reeds firmware on it but even it has problems since I can't get into the Calibrations. That makes no sense to me since that Nano was running fine and has Not been reprogrammed. Do different Nano clones have different boot-loaders installed? I'm pulling out what little bit of hair I have left trying to figure this all out. Thanks for any help. Max KG4PID
On Tuesday, March 23, 2021, 11:34:41 AM CDT, Evan Hand <elhandjr@...> wrote:
Max, There are at least two different versions of Xloader, one is for model airplanes and one for general purpose ATMEGA328p loading.? You need the general purpose one.? I found it here: There are other locations, you need to ensure that one of the choices is the Uno(ATmega328) as well as having the driver loaded (since you can load Blink, then the driver is loaded). Try that and see if the Nextion screen updates.? The symptoms that you are describing agree with what I found when using the wrong Xloader. 73 Evan AC9TU |
Re: Trouble ahead
Tom Very interesting questions.? I have to admit that going back to Forth might be painful, even for us older and long past users of the language.? I do have an Arduino with a TF card socket and a couple of 512 GB TF cards.? That was installed to support work on building a way to page external executables from the TF card into flash memory.? The experiment failed...not because it is not possible but because I reached my own MLI (Maximum level of Incompetence).? The project is still in my files in case I want to resurrect it.? Jack and myself touched on it briefly but it was just a question or two. More recently I have been working on a pico-OS and scripting environment for the Arduino.? It works but still has a way to go before going public with it.? While working on that OS idea it became very apparent that the OS could very easily be made into an RT (Real-Time OS) by simply using the AVR/Arduino microsecond timer to build out each routine called by the main loop to a fixed execution time by adding delay to make each routine comply with the RT granularity.? FYI This idea started out to be an April 1st article but it quickly became obvious that it did have some real potential. Using the standard Arduino IDE layout for a sketch with conventional "void startup" and "void loop"? makes up the basis for the static and dynamic parts of the OS. --------------------------------------- ? /* pico-OS.uno ?* ?Arvid Evans K7HKL ?* ?1 April 2021 ?*/ ? ? ?*/void setup() { ? // put your setup code here, to run once: ? // this becomes the OS BIOS and BOOT section. ? // all variables are defined here and all are global ? // to avoid needing garbage collection. } void loop() { ? // put your main code here, to run repeatedly: ? // put calls to applications here inside this loop. ? // time them and build out each call to match RT granularity. } /* DEVELOPER MANUAL: ?* ?The "void loop" part is the core of the OS. ? ?* ?All variables are Global (avoids needing a garbage collector). ?* ? ?* ?The main loop will contain "long int loop_Start" from AVR ?* ?microsecond clock and "long int loop_End" which allows DEBUG ?* ?mode timing of each run around the loop. ?* ? ?* ?"int DEBUG can be set to any value from zero (DEBUG = OFF) ?* ?to the total number of callable routines in the main loop. ?* ?This allows each routine to have DEBUG ON or OFF for that ?* ?particular routine.? Negative DEBUG modes are global, while ?* ?positive DEBUG values are routine specific. ?* ? ?* ?Each callable routine will have a start value from the AVR ?* ?microseconds clock and an end value which allows calculation ?* ?of the delay build-out to match RT granularity. ?* ? ?* ?Each callable routine in the main loop will do one thing and ?* ?one thing only to keep it small and fast. ?ie, (getting ? ?* ?characters from an attached terminal reads one character only ?* ?per pass around the main loop, and adds that character to a ?* ?"char keyboardBuffer" until it receives a Carriage Return, ?* ?which causes it to process the command stored in ?* ?"keyboardBuffer).? Other callable routines from the main loop ?* ?work in a similar fashion.? This helps with RT granularity and ?* ?makes each transition of the main loop go very fast. ?* ? ?* ?If using C++ routines found in arduino.h, there may be situations ?* ?where a small and direct Garbage Collection Routine ?*? may become necessary.? Only time and use of the C++ ?*? routines can be used to determine if this is necessary. ?* ? ?* ?The user interface or "shell-s script" language has yet to be ?* ?determined.? It may be a partial implementation of the Bourne ?* ?Shell, a Python based shell, or something that is yet to be ?* ?designed and built. ?* ? ?* ?*/ ?/* USER MANUAL: ? * ?Yet to be written. ? */ ? --------------------------------------- Still lots of work to be done.? Will post more when it is finished...or fails. Arv _._ On Mon, Mar 22, 2021 at 8:45 PM Tom, wb6b <wb6b@...> wrote: All this talk about FORTH makes me wonder. |
Re: uBitX V6 no transmit power
#ubitxv6
#ubitx-help
#tx
Nick,
Rereading all of the posts from you, I believe that you could have an LPF problem.? Either in the selection (not so likely as 30 meters is OK), or in the components, or wiring.? You could check to see if the LPF gets warm on 7.15MHz, though I doubt that would be measurable by hand. There is also a possibility of an issue with the first mixer, though why only on 40meters does not make sense.? Visually inspect that area of the mainboard as well as the 30MHz LPF that L1 through L4 are used as inductors.? The signal at that point is very low (less than 200millivolts) so it would only be measurable with either an oscilloscope or spectrum analyzer.?? What test equipment do you have?? Maybe an oscilloscope? I would start with a very close inspection of the 40/30Meter LPF, and verify that the correct relay is bing pulled in when transmitting.? If that checks out, then I would pull one of the toroids and jumper around the filter to see the power into a dummy load.? If there is still an issue, then I am really at a loss as to why only 40meters. If you have a "T" connector for the coax that you are using, and you have the RF detector for your DVM built, Then you can use the detector to measure the voltage across the dummy load and use the formula from QRP-Labs to get an approximate power reading.? That is what the QRP-Labs dummy load is doing on the circuit boards. I would not suggest you do any enhancements until this issue is resolved.? Adding changes on top of the existing problem becomes more difficult to resolve. Here is the section of code where the LPF relays are selected: ========================================================================
void setTXFilters_v5(unsigned long freq){ ??
? if (freq > 21000000L){? // the default filter is with 35 MHz cut-off
? ? digitalWrite(TX_LPF_A, 0);
? ? digitalWrite(TX_LPF_B, 0);
? ? digitalWrite(TX_LPF_C, 0);
? }
? else if (freq >= 14000000L){ //thrown the KT1 relay on, the 30 MHz LPF is bypassed and the 14-18 MHz LPF is allowd to go through
? ? digitalWrite(TX_LPF_A, 1);
? ? digitalWrite(TX_LPF_B, 0);
? ? digitalWrite(TX_LPF_C, 0);
? }
? else if (freq > 7000000L){
? ? digitalWrite(TX_LPF_A, 0);
? ? digitalWrite(TX_LPF_B, 1);
? ? digitalWrite(TX_LPF_C, 0);? ??
? }
? else {
? ? digitalWrite(TX_LPF_A, 0);
? ? digitalWrite(TX_LPF_B, 0);
? ? digitalWrite(TX_LPF_C, 1);? ??
? }
}
=============================================================================== From it, you can see that for both 40 and 30 meters KB1 is on and KA1 and KC1 are off. This is the same code for both the stock and KD8CEC programs. Hope this helps, and Happy hunting for the bug! 73 Evan AC9TU |
Re: Problems with adding Nextion Display and CEC Software
Max,
There are at least two different versions of Xloader, one is for model airplanes and one for general purpose ATMEGA328p loading.? You need the general purpose one.? I found it here: There are other locations, you need to ensure that one of the choices is the Uno(ATmega328) as well as having the driver loaded (since you can load Blink, then the driver is loaded). Try that and see if the Nextion screen updates.? The symptoms that you are describing agree with what I found when using the wrong Xloader. 73 Evan AC9TU |
Re: uBitX V6 no transmit power
#ubitxv6
#ubitx-help
#tx
Just so I don't appear a constant bearer of bad news, I have made several QSOs! 'Real' 59 from Bulgaria and 44 from Ukraine. Both on 20m and 17m - no joy on 80m yet, though I'm not surprised.
What's changed? Nothing much. Reset BFO and Frequency - I can't imagine this had much impact. Perhaps mostly just the confidence of at least 7Watts? I still need to sort 40m TX so will work on this.? Bits for screen upgrade have arrived... Best, Nick |
Re: uBITx v5 with Nextion 3.5"
Here is another set of files for the 3.5" Basic Nextion from K3RTZ.? A quick search did not give a good source for the files, so have attached them here.
73 Evan AC9TU nextion 35 wide 2.1.tft
nextion 35 wide 2.1.tft
nextion 35 wide 2.1_1.tft
nextion 35 wide 2.1_1.tft
nextion 35 wide 2.1.HMI
nextion 35 wide 2.1.HMI
|
Re: Problems with adding Nextion Display and CEC Software
Jack, W8TEE
Max: I've never used the Nextion display, but if you are uploading to the Nano for the first time, make sure you have installed the CH340 or CH341 device driver. (If not installed, just do a search for CH340.) Once you have installed that device driver, most Nano's are clones, so you need to select the old bootloader (i.e., Tools --> Processor "ATMega328P"--> ATMega328P (Old Bootloader). Jack, W8TEE
On Tuesday, March 23, 2021, 12:12:11 PM EDT, Max via groups.io <kg4pid@...> wrote:
I just received my 2.8" Nextion display. I first loaded the tft file into the display. That went correctly (I think) and I now get the new screen on power up. I couldn't get Xloader to work, it just sat there saying "Uploading". Rebooted my win 7 laptop but no change. I tried two different PC's, three different cables and four different Nano's. Same results. But it worked fine a couple of weeks ago when I installed Reeds firmware. So then I installed "RC-Thoughts Software Loader" and it appears to install the selected file with no errors. It comes with two sample hex files, blink fast and blink slow. I tried both and they worked. So then I loaded the CEC firmware and wired up the display. The display looks correct except no data is updated on the display. I've double checked my wiring and even tried different Nano's with no change. Now when I replaced the Nano with the the one that had Reeds firmware on it (this Nano was working correctly and never reprogrammed after the initial upload) everything appears to work except I cannot get into the calibration setting. When I hit the settings icon (looks like a gear) it bring up the screen that lists... Calibrations CW/Morse Setup Reset All Cals/Settings Exit At that point it appears to be locked up. I have to turn the power off/on to get back to a working display.? At this point I'm not sure what to do next. Max KG4PID -- Jack, W8TEE |
Problems with adding Nextion Display and CEC Software
I just received my 2.8" Nextion display. I first loaded the tft file into the display. That went correctly (I think) and I now get the new screen on power up. I couldn't get Xloader to work, it just sat there saying "Uploading". Rebooted my win 7 laptop but no change. I tried two different PC's, three different cables and four different Nano's. Same results. But it worked fine a couple of weeks ago when I installed Reeds firmware. So then I installed "RC-Thoughts Software Loader" and it appears to install the selected file with no errors. It comes with two sample hex files, blink fast and blink slow. I tried both and they worked. So then I loaded the CEC firmware and wired up the display. The display looks correct except no data is updated on the display. I've double checked my wiring and even tried different Nano's with no change. Now when I replaced the Nano with the the one that had Reeds firmware on it (this Nano was working correctly and never reprogrammed after the initial upload) everything appears to work except I cannot get into the calibration setting. When I hit the settings icon (looks like a gear) it bring up the screen that lists... Calibrations CW/Morse Setup Reset All Cals/Settings Exit At that point it appears to be locked up. I have to turn the power off/on to get back to a working display.? At this point I'm not sure what to do next. Max KG4PID |
Re: Trouble ahead- mixed signals?
¿ªÔÆÌåÓýHi Vic, Thanks for your
reply. I was pretty sure that was your point of reference but
it is not safe to assume. My only interest in WSJT modes is to
evaluate propagation and I don't transmit with it (but I
might). I have had some contest and QSO party contacts that
are more interesting. I am glad to have those stations on the
air and when I want them I always know right where to look.
Just like WWV. I have used the other, load handling, digital,
teleprinting modes and enjoyed them the way you have pointed
out. Paying attention to "on topic", my uBitX is one radio I
use to copy those signals these days. I will try LinPSK on the
olde Pi just to see how it does. Once upon a time my computer was big and heavy and so was the display even though the image was small and often hard to read. Now my computers are tiny and easily ride in a shirt pocket. They can reasonably operate from a small battery pack. My displays are on 30 inch HD television screens now :) I have one a little smaller that can also operate from batteries:) And another that mounts on a Pi case! The weight and bulk of the vacuum tube radios could induce injuries and required a lot of power that was wasted in heat energy. Now we can carry some of them in cargo pockets and operate digi modes walking through the state and national forests! As my grandfather used to say - "the only thing good about the good olde days is they are gone!". My 'legacy Pi'
will be used in cli mode in the kitchen to present recipes and
manage grocery lists. Just not both at once! 73, Bill? KU8H bark less - wag more On 3/23/21 6:32 AM, Vic WA4THR via
groups.io wrote:
Yes, Bill, all my comments about the "little Pi" were referring to the Pi-Zero, actually the first and only Pi I have ever had. I gather it runs at about the same or slightly faster than the original Pi, so I think the LinPSK program would work there. That program has no issues on the Pi-zero. As I recall,the Pi-4 is something like 10 or 20 times faster and it is commonly used for decoding FT(x) stuff, but WSJT-X is still a bit marginal on the Pi-zero. I have slowly got it within 4 seconds of finishing decodes before the next cycle (I think it was like 20 seconds behind when I started), and that is with a 10% boost in the clock speed. Still, it may be good enough for my occasional use of that mode. I have made a number of contacts that way. |
Re: Trouble ahead- mixed signals?
Yes, Bill, all my comments about the "little Pi" were referring to the Pi-Zero, actually the first and only Pi I have ever had. I gather it runs at about the same or slightly faster than the original Pi, so I think the LinPSK program would work there. That program has no issues on the Pi-zero. As I recall,the Pi-4 is something like 10 or 20 times faster and it is commonly used for decoding FT(x) stuff, but WSJT-X is still a bit marginal on the Pi-zero. I have slowly got it within 4 seconds of finishing decodes before the next cycle (I think it was like 20 seconds behind when I started), and that is with a 10% boost in the clock speed. Still, it may be good enough for my occasional use of that mode. I have made a number of contacts that way.
I like PSK-31 much more as you actually learn something from each contact and have the opportunity to have a conversation. Fldigi, which many have running on Pi-3 and 4 versions, just was too much for the Pi-zero and it would just lock up. I have toyed with the thought of trying it again with some of the speed improvements I made to run WSJT-X, but LinPSK works very well, so I will probably stick with it. If you look at ADD/REMOVE programs in the Pi menu, v 1.3.5 is what comes up, I think, but the author has upgraded to 1.3.7 to fix some of the logging issues I reported when I started using it. There are a few other minor issues right now and we are still in email conversations about them, but I have had many nice QSOs running with just a Kindle Fire tablet connected via WiFi to the Pi-zero attached to the uBitX, which works even out in the boondocks as the Pi-zero can automatically become a WiFi hotspot if it doesn't log on to a system. =Vic= |
On Mon, Mar 22, 2021 at 04:25 PM, Jim Sheldon wrote:
The metal case is partially shorting to the display¡¯s outer metal contact strip and causing it to be intermittent. ?Had same problem and had to insulate all 4 edges of the display to make it workthanks, i try now and this is the problem :-) Many many thank 73 Andrea IW0HK |
Re: Trouble ahead
On Mon, Mar 22, 2021 at 10:26 PM, Ashhar Farhan wrote:
These are more of hubris projects now.?Yes, that is true. But it is so hard to resist thinking about these kind of things. Can't completely shake that ethos of the days when video hacks like you mentioned were a big thing. ?For a real project it is faster, less expensive, more maintainable and more reliable to use the now much less expensive 32 bit processors. But for the extreme sports aspect of programming it may still be fun doing.? Tom, wb6b |
Re: Trouble ahead
Tom,? the limit is really the? 2K static ram. I tried writing an FIR audio filter. There simply wasn't enough space for that. For one that is good enough, that is. A trivial implementation like that of usdx could still be done.? These are more of hubris projects now.? With more capability available from other devices like the Pico or the STM32 devices, using Arduino is moot. I am impressed by how easy the Arduino movement made it for people like us to take a stab at it, but its days are over. I am still in awe of the fact that Z80 had built-in dynamic ram refresh that could be hacked to make it generate video! It is no longer a viable technology either. - f? On Tue, Mar 23, 2021 at 8:15 AM Tom, wb6b <wb6b@...> wrote: All this talk about FORTH makes me wonder. |
Re: Trouble ahead
All this talk about FORTH makes me wonder.
I wonder if SD card reads, with the Nano for instance, could be optimized well enough that running FORTH byte code from a SD card would be fast enough for many projects.? Just add a SD card connector and suddenly there would be vast amounts of space for code. Or even one of those 99 cent multi megabyte serial flash chips. Many of us already have a SD card in some of our projects by virtual of having a TFT display, with a tag along SD card connector included. ? Then that starts thinking about the more general case of languages that compile to "P" code. How efficient are P byte code interpreter loops compared to a FORTH byte code interpreter loop. Is one more magically efficient than the other.? Because we all likely have ATMega328 and close relatives AVR processors in our parts boxes, it is fun to think of ways to extend their usefulness at low cost.? Here is a random C to FORTH complier I found on Github. Tom, wb6b |