Posts

Posted on

Source code for JackAl

The source code for JackAl is now available for download at our web site, hamradiodesigns.com. I apologize for the delay and that delay is totally on me. Al had his work done months ago. In my defense, it not easy to get 11,000+ lines of C/C++ code to play nice with each other. That said, we think the final result is worth the wait, with features we think everyone will appreciate.

Some details:

There are multiple files in the project. Only one file has a secondary file name of INO. This file contains the setup() and loop() functions and, therefore, all program control elements start in the INO file. All other files are CPP (i.e., C++) files. While this is different than some of you are used to, it brings two advantages to the party: 1) it allows for type checking across files, and 2) it allows for incremental compiles. This second feature can be a real time saver. Instead of compiling almost 400K of source code spread out over 19 files, incremental compiling causes the IDE to only compile those files that have been changed since the last compile.

Line number 4 in the JackAl.h header file contains this line:

  #define DEBUG

In setup(), you’ll see

#ifdef DEBUG

    Serial.begin(115200);

 #endif

In a few places you will also find:

#ifdef DEBUG

   Serial.print(“x = “);

   Serial.println(x);

 #endif

If you leave line 4 in the header file unchanged, the Serial object is compiled into the code which can be useful for debugging, like the Serial.print() lines above. If you comment out line 4, the Serial object is NOT compiled into your program, and all of the subsequent debug print statements are also not compiled into the program. This technique is called “scaffolding” and it allows you to “remove” debug statements without actually removing them from the code. Because you don’t have to retype your debug statements in the highly unlikely event your changes have a bug in them. This can be a real timesaver. You decide what to do with line 4.

Even if you’ve never programmed, you will eventually get tired of seeing Al’s and my names on the Splash screen. The Splash() function is in the INO file and feel free to change it to your own name and call. Note if you want to change something, you must have installed the Arduino IDE and the Teensyduino patch. Details are in manuals.

This code is Open Source, as is the hardware. This is an experimenters platform and we hope you will do just that. That said, we ask that you leave the file header comments unchanged and at the top of the file. Feel free to add whatever you wish after our comments.

There is a JackAl group now (https://groups.io/g/JackAl) and all comments, questions, and support will be done via that Forum. Please check the site from time-to-time, as we know we want to improve a number of things in the software.

Jack, W8TEE

Al, AC8GY

Reference
Posted on

Cooling fans

It is better to have a quiet fan that meets all of the requirements without any extra circuitry that can fail.   You can make a fan more quiet by adding a series resistor.  Experiment to find the right value, but perhaps start with around 500 – 1000 ohms.

Another easy solution is to simply run the fan from the 12V transmit power, assuming that is not what you are already doing. No reason to run the fan while receiving.

If a noisy fan is the only choice, then putting in a controller to minimize the noise while still removing the heat is the next best solution. If properly designed, installed, and tuned, then there would not be a change in the amount of heat that can be removed as the heat sinks get hotter. The response time can get in the way of keeping the finals cool quick enough to not cause an issue. An always on at max fan does not have this issue.

Woody KZ4AK suggests fan controllers are easy to build and minimize noise when not needed.

Something like these…  YMMV

Variable analog – Had to add the 3.3 ohm to reduce induced noise in the uBITx from high current fan.

OR

Switched – OFF/ON

Inexpensive fans can be had surplus, like at:
https://www.allelectronics.com/category/220/fans/1.html
https://www.mpja.com/DC-Axial-Fans/products/48/

Reference
Posted on

New JackAl IO Group

 

Jack, W8TEE and Al AC8GY have formed the JackAl Group for those who may be interested. Because JackAl is an add-on board for the µBITX, we designed the board to be an experimenters’ platform.

While JackAl does use over 200K of flash memory, its processor (a Teensy 3.6) scoots along at 180MHz and leaves about 780K of flash and 230K of SRAM free for experimentation and you still have about a dozen I/O pins to experiment with, too.  They are also using the PJRC companion audio board to augment the DSP that JackAl supports.

Those who may be interested should visit the site:

JackAl groups.io Group

Reference
Posted on

Power output from uBITx plotted

The power output of the µBITx varies according to frequency.

Richard Pushman provided a chart showing the power output of the rig by frequency from 2MHz to 30Mhz for two different supply voltages.   The shape of the peaks and troughs is, of course, influenced by the LPF filters in the output stage.

Reference
Posted on

A power amp to go with your uBITx

Mark, DC3MS has completed his little PA to match his µBITx using eBay modules ( MRF186 + LPF Board ) and a NANO connected via i2c to control it.

The PA board is available on eBay from different sellers. The boards are also used in the MX-P50M. https://vk2qr.wordpress.com/2014/11/25/mx-p50m-hf-amplifier-review/

He added a tandem match from eb104.ru, 4 arduino relays for PTT and ATT (-6dB) and an optocoupler board for switching the LPFs.

The Nano is connected to the ubitx via i2c.  Mark had to insert some lines of code to send the frequency and PTT info to his amplifier.  It was a tight fit in Ian KD8CEC’s software,  as there was not much memory left for additional code.

I tend to forget to switch antennas when changing fom 40/80m to higher bands and blew up a few finals in the past, so the code in the amplifier demands a low power tune after band changes.

When transmitting and high SWR occurs, PTT is disabled.

ATT is enabled on 20-80m as Mark’s µBITx puts out more than 5W on these bands.

Mark will gladly share all details if anybody is interested,

Link to the low pass filter used in the linear amplifier by Mark.

Reference

 

Posted on

New board to replace current v4 board

Ashhar Farhan VU2ESE writes that “there seems to be a light at the end of this tunnel now” with respect to improving the µBITx.

Over the last few weeks he has been talking in the group and off the group with a number of people: Raj, Jerry, Allison, Bill (Meara) and the following represents the consolidated wisdom of this group on the failings (and cures) for the v4 board:

1. The spurs were cause by the harmonic distortion in the 45 MHz IF amplifier. This resulted in a 90 MHz harmonic that mixed with the local oscillator to produce a spur. the local oscillator was at 45 Mhz + tuned freq. The spur was as 90 MHz – local oscillator, that is 90 – (45 + tuned freq) = 45 – tuned frequency. Hence for 21 MHz ,we had a spur at 45-21 = 24 MHz, etc.

The cure was to increase the current in the amp by decreasing R26 from 470 ohms to 220 and introducing a low pass filter between the front-end mixer and the 45 MHz IF amplifier. This consists of L31, C205 and L32. A little snick and solder job can do this on existing boards. WIth these mods, the spurs are well under control. This hack was due to the preliminary work that Raj did followed by taking 50 odd readings of how the spurs moved and analyzing them. in the end, a two variable equation out of a 7th grade algebra book could point out this problem; but we never knew.

2. The harmonics at below 14 MHz were due to the bad routing in the LPF relays. Allison provided a simpler and far better option. The unfortunate part is that the existing boards can’t do this. The other tragedy is that the way these relays are wired . The 28 MHz filter permanantely in the tx output path and the other three LPFs switch in, in series with it. So, the Arduino code for these LPFs is going to be different too.

3. Change of 2nd IF frequency. I am moving the 2nd IF to 11.059 MHz from 12 MHz. This will avoid the frequent problem of having the the 16 mhz oscillator generating spurs inside the IF pass band. The new filter is also a little broader, it is about 2.7 KHz. The audio sounds better, at least I personally prefer it so. Hence, the crystal filters’ caps are changed from 100pf to 68 pf.

4. The LM386 returns. Ashhar Farhan says he is regretting it already. The audio amplifier is now the old frenemy of hams, the LM386. We had to do this because it is the only one that is readily available to manufacture as well as to those who are going to scratch build. This is an open source project that must use easily available components and also strive for a minimum complexity. Using an op-amp with a complementary npn-pnp pair could have worked, but the complexity would have had us to use a bigger board. We wanted to keep the board size same, to allow others to upgrade as well.

5. It is vital that the output above 14 Mhz must be kept to 5 watts. Over-driving this rig will certainly lead to spurs. Check out the captures of 21 MHz. One is with a 5 watts output, the other has it over-driven to 10 watts. It will stay within the legal limits with the supplied electret mic.

Check out the pictures. The green line across the screen is drawn at -43 dbc, the legal limit in the United States for harmonics and spurs.  Ashhar adjusted the RF attenuator so that the transmitted power stayed at -20dbc. See how the distortion adds to the spurs in the two 21 Mhz captures.

v5 board at 21MHz on 10w (overdriven)
v5 Board spurs with 5w (not overdriven)

Ashhar says “If things look good, we will roll with this as v5 board”.   We can expect an update in 2019.

The v5 circuit diagram is attached here: ubitxv5.

Reference
Posted on

Differences between the JackAl and Nextion displays

Most people don’t understand and won’t want to understand the differences between different types of display technologies.

Unfortunately,  the µBITx community has fractured its user base amongst competing screen technologies.   There are many different types of LCD display screens and they are not compatible at all.   

Differences between the Nextion and JackAl displays have been discussed on the BITX20 IO Group list following discussion about whether a Nextion screen used with the KD8CEC firmware could be ported across to the JackAl.  The simple answer is “No”!

Brian N8BDB notes that  it’s not going to be as simple as replacing a driver and rebuilding the application.  The Nextion display works in a very different way than the normal displays most people use for microprocessors like arduino and teensy.

Normally the display is a “dumb” device that just handles displaying the dots.  Software libraries are used to provide basic functionality like drawing lines, boxes, and text.  Touch events are handled completely separately by other libraries.

The Nextion display is the opposite.  The display has it’s own microcontroller, memory, etc. and the arduino communicates with it through a serial interface.  All of the buttons, text, gauges, etc. are prebuilt in the Nextion editor.  The application doesn’t know where they are on the screen.  It just has a name such as “button1” that is associated with a button on a particular screen for instance.  The application just sends a command to the display to change the text of “button1” to “abcd”.  It would require a significant rewrite of the JackAl UI code to make it work with a Nextion display.

The other thing as Jack pointed out is about resolution.  The Nextion displays most people have are much lower resolution than the display used by the JackAl board.  The 2.4″ and 2.8″ Nextion displays are 320×240.  The 5″ Nextion display ($60) is the closest one with similar resolution (800×480) and that is 33% more in price than the display ($40) that JackAl currently uses.  Even the 4.3″ Nextion display is only 480×272.

There are pros and cons of both screen types.  The Nextion costs a bit more per pixel because it has a processor on board, but the demand (in terms of memory and processing power) on the main µBITx is minimal.   The processor and screen communicate using a series of codes.   The Nextion (in theory) can be adapted to have quite different user interfaces for the same functions.  There are, in fact, at least two distinctly different versions of “look and feel” available already.   However, setting up these requires a fairly steep learning curve on the screen management environment.

On the other hand, the JackAl screen (along with all other types of LCD screens) is strongly tied into the firmware of the JackAl teensy processor and amending the “look and feel” of the display requires detailed knowledge of the processor, firmware and the screen programming environment on which the JackAl is built.  It is unlikely that the Nextion will be ported across to the JackAl environment any time soon.  Bite the bullet and buy a new screen!

Reference
Posted on

Should you build your own?

David Balfour says there are a number of hams who should not buy a kit!

The main boards are factory tested, but even simple things seem to trip up many. A Man has to Know his Limits.

He says he is lucky to have purchased two ubitx radios that were not working or fried. Neither had much going wrong except the original owner didn’t have a clue as to what they did wrong. He didn’t even need a VOM to fix either of these kits.

David thinks some hams are born appliance operators. He has a spare ubitx but would hate to sell this to someone who doesn’t want to get some worn out electrons under his fingernails.

The photo of his rig (above) suggests he has a few talents!

Reference
Posted on

Cheap DSP for a QRP rig

Earlier in the year Giuseppe IK8YFW shared a project he has been working on to make a cheap and simple DSP receiver based on the arm cortex stm32f103 processor.  This  module costs less than two US dollars in Far East online shops.

He has implemented two narrow CW filters of about 300 and 700 Hz and two SSB filters with widths of less than 2200 Hz, and less than 3300 Hz.  He also includes a 6-level noise reduction algorithm.

The project is a very cheap solution and is suitable to embed in every QRP project. Details of the project and code is available on github.  It is still at an experimental stage but is worth looking at by experimenters.

The project can be found here:

https://github.com/gcallipo/RadioDSP-Stm32f103

Some test videos of the DSP in action can be found here:

https://m.youtube.com/watch?v=TFcsVX59YbQ

https://m.youtube.com/watch?v=ujDCt_HhbYg

Reference