Hi Dave,
Send me an email to n6qwham@... and I will share the design and code for a substitute controller. Mine has USB/LSB select and involves only one small mod (totally reversible) to the Bitx40 board.
The basic hardware is a Nano, Si5351 .breakout board, a real encoder, a couple of switches and a 16X2 LCD with backpack (uses I2C).
73's
Pete N6QW
|
Do you have a link to specs or the? "att device"?
Anybody with experience implementing CAT rig control have suggestions on
best way to incorporate att device to work as modem embedded in uBITxV6
chassis. To enable more digi modes.
Card was only $15
cheers
|
Re: software update, Reed's code merged
If there is a .hex compiled version of this I¡¯ll test it as well. Thanks
|
(I think Thomas from HF Signals
is most active on the group recently (and Farhan! ))
Thank you,
I had a pleasant surprise on arrival home last night.
My order 24653 had arrived, Ordered 10th January and received
23rd in the UK
Looks like customers have given up on opening your shipments,
all unopened and received the "official" blue stamp !
Thanks again for all you do for the community.
regards Alan
|
Labadee, Aruba, Bonaire, Curacao.
Jack, W8TEE
On Thursday, January 23, 2020, 07:33:10 PM EST, MadRadioModder <madradiomodder@...> wrote:
Which ¡°ham friendly¡± islands are you going to? ? ?
From: [email protected] [mailto:[email protected]] On Behalf Of Jack, W8TEE via Groups.Io
Sent: Thursday, January 23, 2020 6:19 PM
To: [email protected]
Subject: Re: [BITX20] : Thank you! ? I'm in Miami and leave on a 9 day cruise tomorrow and will likely not have Internet access until I get home. I'll look? at it then. Hi Jack,
The code files were named *.cpp even before I started work on it, so I can't take any credit for that. See Ashhar's commit just prior to when I started working on the project for evidence:
I haven't touched the README.md (having too much fun working on the actual code!) but I agree that the wording isn't quite right. Could you make the required changes and then create a pull request into my master branch?
Reed
--
Jack, W8TEE
--
¡_. _._
-- Jack, W8TEE
|
Re: software update, Reed's code merged
Farhan, a little comment, selecting USB/LSB on the screen does not immediately change the clock output until after a press of ptt.
|
Re: software update, Reed's code merged
It took me about 1 minute to incorporate the tuning code. It was fabulously simply written. I did a fresh coding of the text and filling code. Back in those days it was called bitblt-ing (bit block transfers).
Excellent! ? Peeps,
I have done a bit of tweaking to the code of the version 6. the updated code is at? Here is what is new: 1. The 17 meters band now works, it was an oversight to have made a one line mistake in the code. 2. The display is now quite fast. It is a rewrite of the the display routines 3. Reed's momentum tuning has been added to the code.
Do download and test it.
Now, for the longer story...
The way display controller works is that it sets a 'window' within the 320x240 display and then you transfer all the bytes needed to be written to it. They are written to fill up the display left to right each line, from top to bottom.? Thus, if you wanted a letter that is 14 pixels high and 5 pixels across, you will open a window that is 14 by 5 and then transfer 70 pixels?(of 16 bits each) to it. The transfer function of the SPI library works such that it transfers a whole array at once. We don't have the luxury of memory to store a whole array of the screen, hence, we were doing something silly.
We were defining each pixel to be a 1x1 tiny window and painting it with the colour that we needed. Thus, a line that was 320 pixles across needed to draw 320 pixels, one at a time. SLOW!!
The new code snips the drawing into smaller segments of about 64 pixels at a time and transfers them in blocks. the code to fill rectangular blocks is in quickFill and the displayChar.
That apart, Reed's excellent code for better tuning has also been merged. I briefly tested it to work well with the CAT on wsjtx. That's always a big worry. it seems to work quite well.
73, f
|
Re: software update, Reed's code merged
toggle quoted message
Show quoted text
On Jan 24, 2020, at 02:24, Ashhar Farhan <farhanbox@...> wrote:
? Peeps,
I have done a bit of tweaking to the code of the version 6. the updated code is at? Here is what is new: 1. The 17 meters band now works, it was an oversight to have made a one line mistake in the code. 2. The display is now quite fast. It is a rewrite of the the display routines 3. Reed's momentum tuning has been added to the code.
Do download and test it.
Now, for the longer story...
The way display controller works is that it sets a 'window' within the 320x240 display and then you transfer all the bytes needed to be written to it. They are written to fill up the display left to right each line, from top to bottom.? Thus, if you wanted a letter that is 14 pixels high and 5 pixels across, you will open a window that is 14 by 5 and then transfer 70 pixels?(of 16 bits each) to it. The transfer function of the SPI library works such that it transfers a whole array at once. We don't have the luxury of memory to store a whole array of the screen, hence, we were doing something silly.
We were defining each pixel to be a 1x1 tiny window and painting it with the colour that we needed. Thus, a line that was 320 pixles across needed to draw 320 pixels, one at a time. SLOW!!
The new code snips the drawing into smaller segments of about 64 pixels at a time and transfers them in blocks. the code to fill rectangular blocks is in quickFill and the displayChar.
That apart, Reed's excellent code for better tuning has also been merged. I briefly tested it to work well with the CAT on wsjtx. That's always a big worry. it seems to work quite well.
73, f
|
Re: software update, Reed's code merged
You had this type tuning even with? potentiometer tuning. As a concept of fast and slow tune, we used to wonder at that concept.? ?I remember people not liking those days.? As time changes fashions and passions do change. ? Farhan.
Sarma vu3zmv
On Fri, 24 Jan 2020, 12:54 pm Ashhar Farhan, < farhanbox@...> wrote: Peeps,
I have done a bit of tweaking to the code of the version 6. the updated code is at? Here is what is new: 1. The 17 meters band now works, it was an oversight to have made a one line mistake in the code. 2. The display is now quite fast. It is a rewrite of the the display routines 3. Reed's momentum tuning has been added to the code.
Do download and test it.
Now, for the longer story...
The way display controller works is that it sets a 'window' within the 320x240 display and then you transfer all the bytes needed to be written to it. They are written to fill up the display left to right each line, from top to bottom.? Thus, if you wanted a letter that is 14 pixels high and 5 pixels across, you will open a window that is 14 by 5 and then transfer 70 pixels?(of 16 bits each) to it. The transfer function of the SPI library works such that it transfers a whole array at once. We don't have the luxury of memory to store a whole array of the screen, hence, we were doing something silly.
We were defining each pixel to be a 1x1 tiny window and painting it with the colour that we needed. Thus, a line that was 320 pixles across needed to draw 320 pixels, one at a time. SLOW!!
The new code snips the drawing into smaller segments of about 64 pixels at a time and transfers them in blocks. the code to fill rectangular blocks is in quickFill and the displayChar.
That apart, Reed's excellent code for better tuning has also been merged. I briefly tested it to work well with the CAT on wsjtx. That's always a big worry. it seems to work quite well.
73, f
|
Re: software update, Reed's code merged
Ashhar,
Great to see some of these improvements make their way back into the official repo! I'll take a look this weekend.
I also want to give a shout-out to Mark (aka Smitty) who did the interrupt-based encoder piece of the tuning code.
Reed
|
software update, Reed's code merged
Peeps,
I have done a bit of tweaking to the code of the version 6. the updated code is at? Here is what is new: 1. The 17 meters band now works, it was an oversight to have made a one line mistake in the code. 2. The display is now quite fast. It is a rewrite of the the display routines 3. Reed's momentum tuning has been added to the code.
Do download and test it.
Now, for the longer story...
The way display controller works is that it sets a 'window' within the 320x240 display and then you transfer all the bytes needed to be written to it. They are written to fill up the display left to right each line, from top to bottom.? Thus, if you wanted a letter that is 14 pixels high and 5 pixels across, you will open a window that is 14 by 5 and then transfer 70 pixels?(of 16 bits each) to it. The transfer function of the SPI library works such that it transfers a whole array at once. We don't have the luxury of memory to store a whole array of the screen, hence, we were doing something silly.
We were defining each pixel to be a 1x1 tiny window and painting it with the colour that we needed. Thus, a line that was 320 pixles across needed to draw 320 pixels, one at a time. SLOW!!
The new code snips the drawing into smaller segments of about 64 pixels at a time and transfers them in blocks. the code to fill rectangular blocks is in quickFill and the displayChar.
That apart, Reed's excellent code for better tuning has also been merged. I briefly tested it to work well with the CAT on wsjtx. That's always a big worry. it seems to work quite well.
73, f
|
Hi Bert,
I messed around with things a bit more tonight, but while I agree that it feels a bit too eager to jump in some cases, I also haven't figured out a better algorithm yet. If you do happen to change the code and come across something that "feels right" while still allowing for quick band changes, PLEASE let me know!
Reed
|
Anybody with experience implementing CAT rig control have suggestions on best way to incorporate att device to work as modem embedded in uBITxV6 chassis. To enable more digi modes.
Card was only $15
cheers
|
Re: IRF510 insulation question
#v5
Without the long story...
A vendor did that using plastic (Nylon, later Delrin)?screws and it didn't work out well.
Seems the screws would get warm and stretch allowing the mounted device to
loose solid contact and get very much hotter then the screw would melt and fail.
The device aware of its over heated condition would notify the user by releasing
smoke and ceasing operation, promptly and permanently.
The field kit included new transistor, metal screw, nut and a fiber shoulder washer.
The instructions admonished the service person to use the parts and directed,
or else, in bold print.
Allison
---------------------------------
No direct email, it goes to bit bucket due address harvesting in groups.IO
|
Which ¡°ham friendly¡± islands are you going to? ? ?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]] On Behalf Of Jack, W8TEE via Groups.Io
Sent: Thursday, January 23, 2020 6:19 PM
To: [email protected]
Subject: Re: [BITX20] : Thank you!? I'm in Miami and leave on a 9 day cruise tomorrow and will likely not have Internet access until I get home. I'll look? at it then. Hi Jack,
The code files were named *.cpp even before I started work on it, so I can't take any credit for that. See Ashhar's commit just prior to when I started working on the project for evidence:
I haven't touched the README.md (having too much fun working on the actual code!) but I agree that the wording isn't quite right. Could you make the required changes and then create a pull request into my master branch?
Reed
--
Jack, W8TEE
-- ¡_. _._
|
Reed, All:
I'm in Miami and leave on a 9 day cruise tomorrow and will likely not have Internet access until I get home. I'll look? at it then.
Jack, W8TEE
On Thursday, January 23, 2020, 2:03:28 AM EST, Reed N <greenkid336600+groupsio@...> wrote:
Hi Jack,
The code files were named *.cpp even before I started work on it, so I can't take any credit for that. See Ashhar's commit just prior to when I started working on the project for evidence:
I haven't touched the README.md (having too much fun working on the actual code!) but I agree that the wording isn't quite right. Could you make the required changes and then create a pull request into my master branch?
Reed
-- Jack, W8TEE
|
Re: Relative Power indication on Nextion display
Hi MIke,?
Well sort of. In ubitx.h file there is a setting for SMeterLatency, which is by default 3. I changed it to 1 (this means 0.25 sec latency instead of 0.75) and now S-Meter seems more "fluid".
The setting is line 56:
#define SMeterLatency ? 3 ? ? ? ? ? ? ? //1 is 0.25 sec
|
Reed -- Sorry for my slow response getting back to you.? By "aggressive" I mean that the frequency change is too large once it kicks in.? Sometimes I find myself 300-400 KHZ away before I slow my turning.? Perhaps it's just the "operator" who needs a more steady hand!? I'll work with it a while.? It's much better than having no acceleration at all.? Big improvement to add this feature.
Bert N8NN
|
Re: IRF510 insulation question
#v5
On Wed, Jan 1, 2020 at 12:05 PM, Anthony F4HUY wrote:
Question about IRF, does it need to isolate IRF from ground, from metal enclosure, i want to use another kind of heatsink,?
I used a thermal pad between the MOSFETs and heat sinks and used nylon M3 screws and nuts so I didn't have to deal with bushings. ? --
|
where in the UK can i get a raduino clone? or similar ( i have numerous nanos ) for my bitx40 v3?? many thanks? dave c? gw0nvf
|
N0YWB
Mick
Alan de G1FXB
MadRadioModder
N8NN Bert