Date   
Re: UBITX6 arrived today - cracked display

Gordon Gibby
 

Great!



On Jan 28, 2020, at 10:52, support@... wrote:

Hello Philip and the rest.

We did take into account many of the suggestions we received seriously and also looked into the complaints of damages that were brought to our notice. As a result we changed the entire packaging. We are now packing the entire uBitx V6 Kit in Styrofoam cutout boxes with each component separately packed into separate pockets and closed with a Styrofoam cover before being packed in a carton box. There will also be a signed contents list enclosed. Those of you whose orders are being delivered now please do let us know how it has arrived once you receive it. We are also attaching some images of the packaging for all to see.

Thanks,

Thomas

 
Support@...
<Pack1.jpeg>
<Pack 3.jpeg>
<Pack 4.jpeg>
<Pack 5.jpeg>

Re: UBITX6 arrived today - cracked display

support@...
 

Hello Philip and the rest.

We did take into account many of the suggestions we received seriously and also looked into the complaints of damages that were brought to our notice. As a result we changed the entire packaging. We are now packing the entire uBitx V6 Kit in Styrofoam cutout boxes with each component separately packed into separate pockets and closed with a Styrofoam cover before being packed in a carton box. There will also be a signed contents list enclosed. Those of you whose orders are being delivered now please do let us know how it has arrived once you receive it. We are also attaching some images of the packaging for all to see.

Thanks,

Thomas

 
Support@...

Re: 106 top band

Bill Cromwell
 

Hi,

Just to reinforce Bill's reply, I have not yet built the filter for 160 (not 106) but I have been using my V3 to listen to it. I have the filter to allow transmitting on my agenda. It seems to be happy there. In fact, I have dialed down into the broadcast band:) No joy on 630 meters.

73,

Bill KU8H

On 1/28/20 10:03 AM, bill richardson wrote:
It works for me. You will need to add a simple low pass filter.
https://ubitx.net/2018/02/16/top-band-160m-external-lpf/

On Jan 28, 2020, at 9:10 AM, dave <@biker> wrote:

while waiting for my ubitx  v6 to arrive i am contemplating top band any one have any thoughts or ideas on getting the rig to cover top band     dave  c  gw0nvf
--
bark less - wag more

Re: 106 top band

bill richardson
 

It works for me. You will need to add a simple low pass filter.

On Jan 28, 2020, at 9:10 AM, dave <dgclifford@...> wrote:

while waiting for my ubitx  v6 to arrive i am contemplating top band any one have any thoughts or ideas on getting the rig to cover top band     dave  c  gw0nvf

680nH 1210 inductor available?

q q
 

Does anyone out there have 2 extra/surplus 680nH 1210 inductor EPCOS TDK MURATA parts available for sale.

I did the Axicom relay mod and would like to finish up with the addition of the two inductors on my V3 board.

Thank you
Bob, W1EXZ

106 top band

dave
 

while waiting for my ubitx  v6 to arrive i am contemplating top band any one have any thoughts or ideas on getting the rig to cover top band     dave  c  gw0nvf

Re: v4 ubitx stuck in transmit

Curt
 

Ashhar

yes, on my unit.  I have determined that I have an obvious short between my T and R connections, I have not located it yet - might even be one of the wire's from Gordon's board - that I placed in the wrong spot when it came loose.  > 98% of the time the problem is the builder's connections.  I should have this working in a few more steps. 

Let's see how Hamp is doing?  KG5MG my email is on qrz.com if you need any help.  Try connecting a piece of wire to your microphone PTT pins to see if it does the same, in case the microphone button is faulty. 

Curt

Re: Made Mods to V3 uBitx - no longer transmitting #ubitx-help #v3

_Dave_ K0MBT
 

Your problem points to the relays. All but one are in series with the transmit pathway.
I would focus on the daughter board that you added to replace rv1.  I would say that is the most complex part of your modification and you may have an error there. You don't need it. Remove and replace with the stock pot. 

Your comment on your original statement, which is not your problem likely, is that L5 and L7 are not capacitors but inductors. 

If I want to modify anything, I first start with the circuit working then change one thing and test. You sound like you want it to work but take a more rigorous systematic approach.

The hf go-to radio in my shack is my v3 uBITX. I have logged ssb qsos in 6 continents with it.
--
73
Dave
k0mbt
Raduino bracket and Ham_Made_Keys

Re: Antuino - PWR mode at VHF UHF

Gordon Gibby
 

Thank you for that explanation!

On Jan 28, 2020, at 07:43, Raj vu2zap <@Raj> wrote:

Ooz,

Join us in the antuino group..

In Antuino the 8307 only measures the IF at 25MHz so any errors will have to come from the mixer or
the SI chip

Its very accurate upto 150MHz.. -20dbm reads -21dbm on my Mentuino! right through!
Above 150 the reading is a constant -33dbm. This can be corrected in the firmware if you are up to it.

Note the meter is frequency sensitive and not broad band. For an accurate measure you need to fine tune the frequecy
up to 1KHz or so. Userful to measure harmonics.

Raj

At 28-01-20, you wrote:

Is the PWR mode accurate +-1db up to which frequency? I am asking this because I see expected values at HF and going up in frequency I have the impression it gives lower value. Before Antuino I was using a AD8307 board connected to a tester and figure 7 in the AD8307. That figure shows that going higher in frequency up to 500Mhz the same RF voltage indicates more dbm (maybe 10 or so) at 500 Mhz compared to 10Mhz. So it is linear at a given frequency but the same value at a frequency is not the same at a different frequency. Does Antuino take this into account or should I consider accurate at 10Mhz and mentally add the missing dbm according to fig. 7 of the AD8307 datasheet in case I use it at VHF-UHF?


Re: Antuino - PWR mode at VHF UHF

 

Ooz,

Join us in the antuino group..

In Antuino the 8307 only measures the IF at 25MHz so any errors will have to come from the mixer or
the SI chip

Its very accurate upto 150MHz.. -20dbm reads -21dbm on my Mentuino! right through!
Above 150 the reading is a constant -33dbm. This can be corrected in the firmware if you are up to it.

Note the meter is frequency sensitive and not broad band. For an accurate measure you need to fine tune the frequecy
up to 1KHz or so. Userful to measure harmonics.

Raj

At 28-01-20, you wrote:

Is the PWR mode accurate +-1db up to which frequency? I am asking this because I see expected values at HF and going up in frequency I have the impression it gives lower value. Before Antuino I was using a AD8307 board connected to a tester and figure 7 in the AD8307. That figure shows that going higher in frequency up to 500Mhz the same RF voltage indicates more dbm (maybe 10 or so) at 500 Mhz compared to 10Mhz. So it is linear at a given frequency but the same value at a frequency is not the same at a different frequency. Does Antuino take this into account or should I consider accurate at 10Mhz and mentally add the missing dbm according to fig. 7 of the AD8307 datasheet in case I use it at VHF-UHF?

Antuino - PWR mode at VHF UHF

iz oos
 

Is the PWR mode accurate +-1db up to which frequency? I am asking this because I see expected values at HF and going up in frequency I have the impression it gives lower value. Before Antuino I was using a AD8307 board connected to a tester and figure 7 in the AD8307. That figure shows that going higher in frequency up to 500Mhz the same RF voltage indicates more dbm (maybe 10 or so) at 500 Mhz compared to 10Mhz. So it is linear at a given frequency but the same value at a frequency is not the same at a different frequency. Does Antuino take this into account or should I consider accurate at 10Mhz and mentally add the missing dbm according to fig. 7 of the AD8307 datasheet in case I use it at VHF-UHF?

Re: v4 ubitx stuck in transmit

Ashhar Farhan
 

Does it continue to be stuck even if you take out the connectors from the main board?
- f

On Tue, Jan 28, 2020 at 2:32 AM Curt via Groups.Io <wb8yyy=yahoo.com@groups.io> wrote:
Hamp

I think yours may be a horse of a different color.  Have your tried this on more than one band?  I presume you installed the 4.7k resistor in the PTT line (yes it is needed even if you don't do CW)?  Try to key the CW path to see if it does the same thing. 

I don't know if you adjusted the transmit drive to try to get more power?  That could be another factor in this.  Make sure you have a connection between circuit board ground and the outside of the coax connector - I had to scrape paint to get a good electrical contact. 

You are doing pretty well to get the ubitx this far!  Also a v5 needs few mods.  And often all that you need is that multi-meter. 

don't key down for long while you figure this out. 

Curt wb8yyy

Re: uBitX on CW #v6

Reed N
 

Ron,

You're absolutely right! I assumed it would act like the Arduino library delays, and instantly return if 0, but looks like it uses "<=" instead of "<", which will (almost always) wait a minimum of 10ms. Thanks for the correction :) I removed them in 8db6401.


Reed

Re: uBitX on CW #v6

W2CTX
 

Please take this as information and not criticism:

The RX->TX delay is a constant 50 but is times 2 in the call to active_delay.
Even if you set the constant to zero you still get a 10ms delay from active_delay.

Better to remove both active_delay calls to eliminate any delay.

rOn

On January 27, 2020 at 11:44 PM Reed N <greenkid336600+groupsio@...> wrote:


"Latest github file" meaning Ashhar's master branch, I assume?

I kind of see what you're saying about there not being a single standard, but I think you're also missing some of the picture. So far, the changes in my master version include:

* Faster screen updates (when the stock was still snail-speed)
* Faster tuning knob response (when stock was using polling - big thanks to Mark on this one, which I merged in)
* Smoother tuning acceleration
* Tiered menus with help text
* Non-return-to-default calibrations

Of these, the only one that strikes me as "user preference" would be the acceleration, and maybe I should add an option to turn it off. The rest I don't think are custom tailored to my person in any way - I aimed for general usability improvements, and many of them are based on OTHER people specifically asking for them. I've also tried to keep things generic, so that if Ashhar wants, he could merge all of my changes back in to his "official" branch. I'm making changes because I want to make the software better, but it's not my job, and I can't fix everything at once, so have some patience.

I think you're confused about the parameters. The "CW DELAY" option in Ashhar's code is NOT the RX->TX delay. He has that hard coded as 50ms, which I've changed to 0ms (aka no delay) in the cw-tx-issues branch mentioned in https://groups.io/g/BITX20/message/75378. The "CW DELAY" is ONLY the delay from TX->RX. Changing the value of "CW DELAY" will not fix your problem, as I said in https://groups.io/g/BITX20/message/75360

SET FREQ and BFO are two settings that reset to default when you enter Ashhar's setting menu for them. This is not the case in my version, since several people complained about it, and I had some issues with it too.

git (the utility) and GitHub are tools that are literally designed to track changes between code versions, and allow you to tag versions. If I were to build my own custom toolchain for this project, I'd have it auto-version the code so that it displayed the exact commit it was built with, but unfortunately the stock Arduino chain doesn't allow for that, and I don't want to roll a custom toolchain, because that's moving away from the "user-friendly" side of things. However, I do intend to get a version put into my code at some point in the near future. For now, if you just note the commit number that you build from (e.g. Ashhar's master is currently at 4e0516076a43401c506862b93e4196331f519c49), you will have all of the information you need to exactly identify what the code was.

Reed


Re: uBitX on CW #v6

Reed N
 

"Latest github file" meaning Ashhar's master branch, I assume?

I kind of see what you're saying about there not being a single standard, but I think you're also missing some of the picture. So far, the changes in my master version include:
  • Faster screen updates (when the stock was still snail-speed)
  • Faster tuning knob response (when stock was using polling - big thanks to Mark on this one, which I merged in)
  • Smoother tuning acceleration
  • Tiered menus with help text
  • Non-return-to-default calibrations

Of these, the only one that strikes me as "user preference" would be the acceleration, and maybe I should add an option to turn it off. The rest I don't think are custom tailored to my person in any way - I aimed for general usability improvements, and many of them are based on OTHER people specifically asking for them. I've also tried to keep things generic, so that if Ashhar wants, he could merge all of my changes back in to his "official" branch. I'm making changes because I want to make the software better, but it's not my job, and I can't fix everything at once, so have some patience.

I think you're confused about the parameters. The "CW DELAY" option in Ashhar's code is NOT the RX->TX delay. He has that hard coded as 50ms, which I've changed to 0ms (aka no delay) in the cw-tx-issues branch mentioned in https://groups.io/g/BITX20/message/75378. The "CW DELAY" is ONLY the delay from TX->RX. Changing the value of "CW DELAY" will not fix your problem, as I said in https://groups.io/g/BITX20/message/75360

SET FREQ and BFO are two settings that reset to default when you enter Ashhar's setting menu for them. This is not the case in my version, since several people complained about it, and I had some issues with it too.

git (the utility) and GitHub are tools that are literally designed to track changes between code versions, and allow you to tag versions. If I were to build my own custom toolchain for this project, I'd have it auto-version the code so that it displayed the exact commit it was built with, but unfortunately the stock Arduino chain doesn't allow for that, and I don't want to roll a custom toolchain, because that's moving away from the "user-friendly" side of things. However, I do intend to get a version put into my code at some point in the near future. For now, if you just note the commit number that you build from (e.g. Ashhar's master is currently at 4e0516076a43401c506862b93e4196331f519c49), you will have all of the information you need to exactly identify what the code was.


Reed

Re: uBitX on CW #v6

Reed N
 

Hi Andy,

If you go to my cw-tx-issue branch (https://github.com/reedbn/ubitxv6/tree/cw-tx-issues) and download that code, I have set the constant mentioned in my comment (https://groups.io/g/BITX20/message/75357) to 0. Compile this version, and see if it transmits straight key for you nicely or not. In my testing (with the PTT button) it seemed to do the right thing, but I'd be interested to get a second opinion on it before I merge it into my master.


Reed

Re: software update, Reed's code merged

Andy_501
 

OK Reed thanks for tip re download. I did it with green Dwnld/Clone button this time and it downloaded the necessary files. I was able to save them per the instructions this time and Arduino IDE performed as expected correctly this time.

The previous download I was selecting each highlighted link as a target to save and it appears under the github system that those are html ref info files of some sort. I thought they were the target files I had to download and save for compiling kind of like what one does for the component parts of the FLDigi suite on sourceforge.

water under the bridge now at least I can verify/compile successfully and export the hex files with and without the bootlader

Thanks Again

73 Andy

On 2020-01-27 10:38, Reed N wrote:
Andy, it looks like you may have saved the webpage display of nanogui rather than the actual raw code. Try downloading again using the green "clone or download" button. It should give you a zip file that has all of the raw code.


Reed

Re: uBitX on CW #v6

Andy_501
 

OK Reed will give it another look SAP

On 2020-01-27 11:15, Reed N wrote:
Hi Andy,

On the v6 there isn't a menu option for it. Looks like the value was copied from the CEC software, and is now hard coded as 50ms. I'll make a new branch with that change to let you try it out if you can't make the change yourself.


Reed

Re: uBitX on CW #v6

Andy_501
 

Thanks Reed I will look forward to it. But not being able to run CW mode normally with a standard hand key as well as not finding a solution to the problem of the latest github file and Arduino IDE to allow me or other noobie students to be able to correct things for themselves is a real BIG NEGATIVE as far as using this as a kit for practical lab time  on a course for sure.

Something else I have noticed here in this group there are many keen and interested chaps that are able to code and generate the proper files to upload and happily willing to help by giving others hex files to up load; problem with that is so many different priorities and interests are involved and what one person has tailored or coded into their preferred priority may not be what the standard GitHub original code file contains. So by accepting these files any default variable values may differ depending on each opr's preferred modes of operation.

So by accepting just a hex file a noobie can have a fair bit of difficulty trying to keep a standard code set to use. As an example setting the default code delay to "1" or someone else uses "50"; In my case the hex file that I received has cw delay of only 1 of 2 choices 100 ms or 200 msec and nobody else mentions these as options at all. Without an ino file associated with that specific hex file one can't open it and compare where the differences exist to kind of keep things in some semblance of a standard package.

Again if Ashhar comes out with another "final" update release on his GitHub link, we have no real idea what versions of tuning speeds and acceleration coding is including or code delays etc. In my case the latest release I have running has "SET FREQ' at a totally different frequency than the original prompt asked for (ie 10,000KHz)  and the BFO zero beat freq is different again. If I get things working properly where I can check coding myself and modify it I will have to have an ongoing spreadsheet file to itemmize all the differences from the initial standard so that when a new one is issued I can adjust the release in the arduino IDE to meet my custom needs before I export the code to a master .ino file and associated hex files to upload into the system. I see the version number on the main display in the bottom corner, but that could conceivably be the same for any number of customized packages from different oprs and with no .ino file to check into it can be totally different.


On 2020-01-27 11:15, Reed N wrote:
Hi Andy,

On the v6 there isn't a menu option for it. Looks like the value was copied from the CEC software, and is now hard coded as 50ms. I'll make a new branch with that change to let you try it out if you can't make the change yourself.


Reed

Sensitive Mike cord

Maurice Bersan
 

Gday folks, 

I have just discovered I have a sensitive mike cord, by that I mean if I touch it my version 5 goes into transmit or just sends a carrier. It only happens on certain frequencys mainly 80meters and only when I hook up to my 80 40 20mtr mobile multitap antenna or random length  wire and only with swr lower than 1.5:1.
I have checked grounds and ground loops multiple times and also other mikes but still no luck. I have used shielded hook up wire on the internal antenna connection as well.  No prob on my 80mtr dipole. 
Any ideas out there? 
Cheers for any help
Maurice
Vk6hly