Date   
Re: separate CAT jack, without using the USB cable #ubitx #cat #raduino #arduino

Scott Norby
 

I do not think that would work.  The TX and RX pins on the Nano are RS232, not USB.

Re: Upgrades and backward compatibility

ajparent1/KB1GMX <kb1gmx@...>
 

Jack,

Refactoring is not a user thing, I never intended that.  That refactor
is on the developers to do and put a version to the public.    Also
comments of code efficiency were for V4.3 Raduino code.  When
I played with it it was so sluggish it did not keep up with the encoder
well, the code was anything but modular and was a hard to update.

Its purpose (a refactor) is to make suitable space IF NEEDED so the
menu-system (like the calibration menu) can set a bit/byte in the Eeprom
to mark the system as V5 or preV5 and take the specific action.

Properly done by the developers the user should not have to do coding,
it should be not a big deal to query if the user has V5 or not and
internally configure as needed.

Obviously I should have made clear this is for the base Raduino and the
JackAl, and Nextion user have their own special fun.


Allison

Re: separate CAT jack, without using the USB cable #ubitx #cat #raduino #arduino

Jerry Gaffke
 

That can work, if you include an external USB to 5v tolerant UART converter such as this:
     http://www.oddwires.com/cp2102-serial-adapter-module-usb-to-rs232-with-jumper-wires/

How to do it is documented at the bottom of this post:
    https://groups.io/g/BITX20/message/50027
In that write-up, I mention tying the 5v pin from the CP2102 to the 5v pin of the Raduino,
only do that if you want to power the Raduino from the host's USB port.
In your case where you have the Raduino installed in the uBitx, do not connect
up that 5v wire, as it is better to let the LM7805 on the Raduino supply the 5v.

The CP2102 is primarily 3.3v, but the pins are 5v tolerant.
The Nano has 5v TXD/RXD pins.
It works.

There are plenty of other USB-to-UART adapters that could work for you, 
but that happens to be the one I used.
Some may give you more trouble with installing the needed software driver,
my CP2102 worked out of the box on an Ubuntu host without needing a driver installed.
And some USB-to-UART adapters may not be 5v tolerant.

Toward the top of that post there's a link to the schematic for the Nano clones we use:
       http://actrl.cz/blog/wp-content/uploads/nano_ch340_schematics-rev1.pdf
in case you wanted to figure things out more thoroughly.
Datasheets for all the IC's involved are easily found on the web.

Jerry, KE7ER



On Sun, Feb 10, 2019 at 01:00 PM, Sascha Bohnet | DL5SMB wrote:

Hello everybody,

can anybody tell me, if it is possible to realize / install a separate cat jack without using the present USB port,
by going straight to Pin 1, Pin 2 and Ground on the Arduino Nano?

If I have understood correctly the built in cat interface  in KD8CECs firmware uses the USB connector

just as an RS232/TTL converter

Am i right, if I assume, that it should be possible to solder some wires to D0 and D1 (RX + TX) and ground and then install

a MINI-DIN 8 socket to the uBITX like in an FT817?

I am asking because I am building TF3LJs Magnetic Loop Controller https://sites.google.com/site/lofturj/to-automatically-tune-a-magnetic-loop-antenna at

the moment, which communicates with the tranceiver via cat for tuning the antenna. This interface uses just these three lines. So I need to make them talk :-)

I would just try it, but am a little bit unsure if i might damage something, if I am wrong. I am not really fond of grilling the Raduino.

Sascha

Re: Upgrades and backward compatibility

Jack, W8TEE
 

Hi Allison:

The JackAl system is a bit unusual because the user and the programmer might be the same person. So when you said refactoring, to me that meant the user might be changing things, but you're right, that doesn't need to be the case. Still, we hope users will want to dig in and experiment with the JackAl system. There are plenty of idle memory resources and we left about a dozen pins free, too. I also agree that users should not have to do any coding if they don't want to w/r to a Ver 5 versus earlier boards.

Jack, W8TEE

On Monday, February 11, 2019, 2:33:26 PM EST, ajparent1/KB1GMX <kb1gmx@...> wrote:


Jack,

Refactoring is not a user thing, I never intended that.  That refactor
is on the developers to do and put a version to the public.    Also
comments of code efficiency were for V4.3 Raduino code.  When
I played with it it was so sluggish it did not keep up with the encoder
well, the code was anything but modular and was a hard to update.

Its purpose (a refactor) is to make suitable space IF NEEDED so the
menu-system (like the calibration menu) can set a bit/byte in the Eeprom
to mark the system as V5 or preV5 and take the specific action.

Properly done by the developers the user should not have to do coding,
it should be not a big deal to query if the user has V5 or not and
internally configure as needed.

Obviously I should have made clear this is for the base Raduino and the
JackAl, and Nextion user have their own special fun.


Allison

Re: separate CAT jack, without using the USB cable #ubitx #cat #raduino #arduino

Jerry Gaffke
 

I'll now drive this thread off into the weeds regarding an obscure issue
with some older CP2102 USB-to-UART modules.
Most people won't care.


While verifying how the CP2102  USB-to-UART converters work, I ran into this post
    https://www.silabs.com/community/interface/forum.topic.html/cp2102_3_3v_outputi-EaVr
where the second to the last post says:

PBudmark    Replied Jul 08 2017, 12:37 PM
There is a major design flaw in the board, RST-pin (9) is connected to 5.0V (VBUS).
This is reported deep into a forum on Banggood but not properly informed to buyers.
Quote: The problem with the 3.3V line at 4.2 is due to the RST input being tied not to 3.3 V out but to the Vbus in (5V) this back feeds into the 3.3V line pulling it up above spec, cut the trace you see coming from pin 9 before it reaches the capacitor, then optionally pull it to 3.3 via a 4k7 resistor to pin 6. This also seems to solve the variability with Win10     Posted 2017-02-22 09:12:56 by instoned @t aol dot com
 
The post includes a photo, showing that pins 8 and 9 of his CP2102 chip got shorted together.
From the diagram at the bottom of the first page of the CP2102 datasheet
    https://www.silabs.com/documents/public/data-sheets/CP2102-9.pdf
you can see that pin8 is 5v coming in from the USB host computer.
Pin 9 is the RST (reset) pin of the CP2102 chip, and should be pulled high to 3.3v through a pullup resistor.

The CP2102 modules I got from oddwires.com  a few years ago do not have this flaw.
My modules do not have a ceramic cap placed near pins 8,9 of the CP2102 as in the above post,
the appearance of my module is significantly different.
The current CP2102 modules available from Banggood are different than the post above or mine:
    https://www.banggood.com/Wholesale-USB-To-TTL-COM-Converter-Module-buildin-In-CP2102-New-p-27989.html?akmClientCountry=America&cur_warehouse=CN
Oddwires now pictures yet a fourth build, with the CP2012 chip placed at a diagonal:
    https://www.oddwires.com/cp2102-serial-adapter-module-usb-to-rs232-with-jumper-wires/

So hopefully, the incorrect CP2102 modules are now long gone from the supply chain.
I'd go with the Oddwires product, as it has access to some additional signals (CTS, RTS, DSR, ...)
along the sides of the board.

It seems the incorrectly built CP2102 modules worked, though having Vdd up at 4.3v
is stressing the CP2102.chip.  And if driving a 3.3v processor with a 4.3v TXD,
you might be slightly stressing that processor as well.
Since our Nano has 5v IO, I doubt anything catastrophic would occur other than having 
the CP2102 module possibly fail.

Jerry

On Mon, Feb 11, 2019 at 11:42 AM, Jerry Gaffke wrote:
How to do it is documented at the bottom of this post:
    https://groups.io/g/BITX20/message/50027
In that write-up, I mention tying the 5v pin from the CP2102 to the 5v pin of the Raduino,
only do that if you want to power the Raduino from the host's USB port.
In your case where you have the Raduino installed in the uBitx, do not connect
up that 5v wire, as it is better to let the LM7805 on the Raduino supply the 5v.

The CP2102 is primarily 3.3v, but the pins are 5v tolerant.
The Nano has 5v TXD/RXD pins.
It works.

Re: Upgrades and backward compatibility

Evan Hand
 

I would agree with Alison, put the bit in EEPROM and to build on that, it could be selectable on first startup or reboot back to factory.  No need to maintain seperate code bases if done this way.

Great Idea Allison!

73
Evan
AC9TU

Re: Upgrades and backward compatibility

Jack, W8TEE
 

I was at Hamcation when this thread started, so I may have missed things. Anyway, is there something in the hardware that can be read at runtime to determine which board is being used, or is the EEPROM bit set "at the factory" when it's produced? If the latter, how does the code reset the bit if they let the magic smoke out of the factory Nano? It would be really nice if "something" (e.g., a port perhaps) has the board version identifier accessible by the software at runtime and act accordingly. Like I said, maybe that's what people have in mind, and that would make it very easy to determine the version of the host board.

Jack, W8TEE

On Monday, February 11, 2019, 3:42:46 PM EST, Evan Hand <elhandjr@...> wrote:


I would agree with Alison, put the bit in EEPROM and to build on that, it could be selectable on first startup or reboot back to factory.  No need to maintain seperate code bases if done this way.

Great Idea Allison!

73
Evan
AC9TU

Re: Upgrades and backward compatibility

W2CTX
 

I had already suggested directly to Farhan earlier this morning about using the highest EEPROM byte
to designate the version number. However now that I have thought about it the, EEPROM is
in the nano and not on the board. The raduino can be moved between boards! The designation
must be on the board.

Also because the incompatibility is not complicated, everyone is looking for an easy fix.
The next incompatibility issue may be more complicated. Really need to think this through
rather than "shooting from the hip".

rOn

On February 11, 2019 at 3:58 PM "Jack Purdum via Groups.Io" <jjpurdum=yahoo.com@groups.io> wrote:


I was at Hamcation when this thread started, so I may have missed things. Anyway, is there something in the hardware that can be read at runtime to determine which board is being used, or is the EEPROM bit set "at the factory" when it's produced? If the latter, how does the code reset the bit if they let the magic smoke out of the factory Nano? It would be really nice if "something" (e.g., a port perhaps) has the board version identifier accessible by the software at runtime and act accordingly. Like I said, maybe that's what people have in mind, and that would make it very easy to determine the version of the host board.
Jack, W8TEE

On Monday, February 11, 2019, 3:42:46 PM EST, Evan Hand <elhandjr@...> wrote:

I would agree with Alison, put the bit in EEPROM and to build on that, it could be selectable on first startup or reboot back to factory.  No need to maintain seperate code bases if done this way.

Great Idea Allison!

73
Evan
AC9TU


Re: Upgrades and backward compatibility

ajparent1/KB1GMX <kb1gmx@...>
 

Jack,

No.  The V5 change that most impacts code is the change is the relay wiring.
and you know you have one or not.  So the only way to indicate it is code can
ask a simple question at first boot or doing the calibration phase.

I believe its factory code, IE a variation for V5 of the previously version used
with the section to select the relays updated.  PRolem is if they sell a Raduino
with code now they have to get it right or likely its wrong depending on what
the customer expects.

It impacts the base Raduino users as most are not into Arduino and programming
they bought a radio.  And there are a lot of them.  Though for the jackAl you also
have compatibility to deal with.

Allison

Re: Upgrades and backward compatibility

ajparent1/KB1GMX <kb1gmx@...>
 

rOn,

The code knows its version number and all.  What it doesnt know is if the board is
a V3/4 or V5 and cannot know as there is no "signal" from the board.

So likely as can guess the last V4 board had a specific code and the first V5 had
different code for the differing relay layout.

I believe the code is even a copy of what I put in the wiki from some months ago.

The issue is for the non-coder out there that thought he bought a radio or
someone that ends up in the middle of all this without much of a clue. 

Considering most read this whole mess as Email the historical body is largely
lost as to what happened and why.  Its especially true with newcomers 
No one looks at the archives on the web and likely even knows the wiki
has info or they can add to it.  So every few weeks or months the cycle
starts anew.

Allison

Re: Upgrades and backward compatibility

Jack, W8TEE
 

Allison:

Maybe others would be interested in using what we do. Upon power up, we read byte 0 of EEPROM and if it's not a specific value, we assume this is the first time they have run the software on this rig, so we launch a setup routine. The Teensy doesn't really have EEPROM, but emulates it. That makes no difference. If we don't see that specific value, we run setup. (The user can also select setup at a later time if they wish.) Since we are only reading the first byte, there is a 1 in 256 chance that they haven't run setup but it appears that they have. After they run setup, we write that specific value to address 0 in EEPROM. A virgin Nano has all EEPROM bytes initialized to 0xFF, so you could check for that, too. However, I suppose someone could be rewriting byte 0 in EEPROM which would mess things up. If we can agree to leave a byte (first, last, whatever...) unused by programmers, we should be able to read it and decide what board we're working with.

Might work...

Jack, W8TEE

On Monday, February 11, 2019, 4:20:05 PM EST, ajparent1/KB1GMX <kb1gmx@...> wrote:


Jack,

No.  The V5 change that most impacts code is the change is the relay wiring.
and you know you have one or not.  So the only way to indicate it is code can
ask a simple question at first boot or doing the calibration phase.

I believe its factory code, IE a variation for V5 of the previously version used
with the section to select the relays updated.  PRolem is if they sell a Raduino
with code now they have to get it right or likely its wrong depending on what
the customer expects.

It impacts the base Raduino users as most are not into Arduino and programming
they bought a radio.  And there are a lot of them.  Though for the jackAl you also
have compatibility to deal with.

Allison

Re: separate CAT jack, without using the USB cable #ubitx #cat #raduino #arduino

AndyH
 

On Sun, Feb 10, 2019 at 03:00 PM, Sascha Bohnet | DL5SMB wrote:

Hello everybody,

can anybody tell me, if it is possible to realize / install a separate cat jack without using the present USB port,
by going straight to Pin 1, Pin 2 and Ground on the Arduino Nano?

If I have understood correctly the built in cat interface  in KD8CECs firmware uses the USB connector

just as an RS232/TTL converter

Am i right, if I assume, that it should be possible to solder some wires to D0 and D1 (RX + TX) and ground and then install

a MINI-DIN 8 socket to the uBITX like in an FT817?

I am asking because I am building TF3LJs Magnetic Loop Controller https://sites.google.com/site/lofturj/to-automatically-tune-a-magnetic-loop-antenna at

the moment, which communicates with the tranceiver via cat for tuning the antenna. This interface uses just these three lines. So I need to make them talk :-)

I would just try it, but am a little bit unsure if i might damage something, if I am wrong. I am not really fond of grilling the Raduino.

Sascha

 
Sascha,

  THANK YOU for linking to this project - I've been trying to figure out how to put a loop in my attic for close to three years - this is PERFECT!  

   I noticed that Loftur has a 'pass-through' mode.  I wonder if that will do the job? 
The USB port can also be configured for Serial port <==>USB port passthrough mode, enabling computer control of the transceiver.
   I'm interested in exploring this as well, as I'm hoping to use cat to let my µBITX talk to this box an an off-board PA.

  73, Andy, KG5RKP

Re: Upgrades and backward compatibility

Jerry Gaffke
 

No hardware port to read when trying to distinguish between v3/v4 and v5 main uBitx boards, nfortunately.
Making a decision for the user by reading flash or eeprom seems a bad idea,
as Raduino's get swapped around.

Just do something simple, don't try to hide this minor complexity with something that will add more unknowns.
I'd just put a   "#define V25"  at the top of the main *.ino file, gets commented out for v3,v4.

For the special case of a club workshop where there are rigs going through of different flavors,
I suppose there it might make sense to have a Raduino that can power up for either v4 or v5.
That could be done by either a menu entry, or by sensing if FCTN is pressed at power up. 

Going forward, we can assume most boards will be v5.
So make it easy for v5 users.

Jerry



On Mon, Feb 11, 2019 at 12:59 PM, Jack Purdum wrote:
I was at Hamcation when this thread started, so I may have missed things. Anyway, is there something in the hardware that can be read at runtime to determine which board is being used, or is the EEPROM bit set "at the factory" when it's produced? If the latter, how does the code reset the bit if they let the magic smoke out of the factory Nano? It would be really nice if "something" (e.g., a port perhaps) has the board version identifier accessible by the software at runtime and act accordingly. Like I said, maybe that's what people have in mind, and that would make it very easy to determine the version of the host board.
 
 

Re: Upgrades and backward compatibility

Arv Evans
 

Looking back at some of the commercial systems that I have worked on over the years, it
comes to mind that some of these systems were able to read specific voltage or ground points
on motherboards and daughter boards to determine what version they were working with.
In the uBITX, BITX-40, etc. we have both the Raduino and main board to consider, and
possible some other boards and variants in hardware configurations. 

1) We need to have ability for the software to determine which Raduino hardware version it
      is installed on.

2) We need to have ability for the software to determine which uBITX or BITX-40, or BITX-nn
     it might be supporting. 

3)  Maybe we even need to know whether the RF PA section is running on the same voltage
     as the rest of the boards?

4)  Should identification of boards and configurations be the responsibility of users, manufacturers,
      or should it be totally automatic based on sensing by the control board software?  Should
      this identity function be adaptive, preset, set-once, or easily user settable?

Of course this can be carried to illogical extreme.  Just how much identity function do we
need in an environment that involves several main-boards and several support/control boards?

Arv K7HKL
_._


On Mon, Feb 11, 2019 at 3:22 PM Jerry Gaffke via Groups.Io <jgaffke=yahoo.com@groups.io> wrote:
No hardware port to read when trying to distinguish between v3/v4 and v5 main uBitx boards, nfortunately.
Making a decision for the user by reading flash or eeprom seems a bad idea,
as Raduino's get swapped around.

Just do something simple, don't try to hide this minor complexity with something that will add more unknowns.
I'd just put a   "#define V25"  at the top of the main *.ino file, gets commented out for v3,v4.

For the special case of a club workshop where there are rigs going through of different flavors,
I suppose there it might make sense to have a Raduino that can power up for either v4 or v5.
That could be done by either a menu entry, or by sensing if FCTN is pressed at power up. 

Going forward, we can assume most boards will be v5.
So make it easy for v5 users.

Jerry



On Mon, Feb 11, 2019 at 12:59 PM, Jack Purdum wrote:
I was at Hamcation when this thread started, so I may have missed things. Anyway, is there something in the hardware that can be read at runtime to determine which board is being used, or is the EEPROM bit set "at the factory" when it's produced? If the latter, how does the code reset the bit if they let the magic smoke out of the factory Nano? It would be really nice if "something" (e.g., a port perhaps) has the board version identifier accessible by the software at runtime and act accordingly. Like I said, maybe that's what people have in mind, and that would make it very easy to determine the version of the host board.
 
 

Re: Upgrades and backward compatibility

ajparent1/KB1GMX <kb1gmx@...>
 

Jerry,
>>>Just do something simple, don't try to hide this minor complexity with something that will add more unknowns.
I'd just put a   "#define V25"  at the top of the main *.ino file, gets commented out for v3,v4.<<<<<

For me its trivial and not a second thought. 

For the first time bitx who is not into Arduino and all I'd say that is a very unfun thing to be mild
about it.  Then you and every one gets to tell the user again where to get the IDE, how to deal
with W10 (or mac) and the ch340 driver, how to identify the USB device port, where to edit the
code and of course answer all the questions what does error###### mean. and the poor user
is now well over their head and learning to program. 

And all he/she wanted was a radio.

Also where there are choices, Murphy's law: IF there are two choices the selected one will be
wrong.  

Allison

Re: Upgrades and backward compatibility

Jerry Gaffke
 

Too late.
And not that big of a deal anyway.

Has not been much of a problem for Bitx40 vs v3/v4
And won't be much of a problem for v3/v4 vs v5.

I could imagine ways of designing the Bitx40, v3,v4 and v5 such that they could be distinguished. 
Perhaps light pullups/pulldowns on TXA,B,C (and have them drive FET,'s, not 2n3904's).
But that's more trouble than it's worth, and would have required knowing  back in 2016
that the uBitx would be coming along.

Jerry


On Mon, Feb 11, 2019 at 02:36 PM, Arv Evans wrote:
Looking back at some of the commercial systems that I have worked on over the years, it
comes to mind that some of these systems were able to read specific voltage or ground points
on motherboards and daughter boards to determine what version they were working with.
In the uBITX, BITX-40, etc. we have both the Raduino and main board to consider, and
possible some other boards and variants in hardware configurations. 
 

Re: Upgrades and backward compatibility

Jerry Gaffke
 

My understanding is that most people burning other than stock firmware do so through the IDE.
Some were burning binaries, but generally the advice was recompiling was easier.

Yes, if sending out binaries, they would have to be compiled for one or the other.

> For me its trivial and not a second thought. 

Apparently.
The second thought would have been that we might want to know
what you have in mind.

Ideally, hfsignals ships with code that has all the features that anybody could possibly want.
And fits in a Nano. 
I'm not holding my breath.

Jerry


On Mon, Feb 11, 2019 at 02:52 PM, ajparent1/KB1GMX wrote:
Jerry,
>>>Just do something simple, don't try to hide this minor complexity with something that will add more unknowns.
I'd just put a   "#define V25"  at the top of the main *.ino file, gets commented out for v3,v4.<<<<<

For me its trivial and not a second thought. 

For the first time bitx who is not into Arduino and all I'd say that is a very unfun thing to be mild
about it.  Then you and every one gets to tell the user again where to get the IDE, how to deal
with W10 (or mac) and the ch340 driver, how to identify the USB device port, where to edit the
code and of course answer all the questions what does error###### mean. and the poor user
is now well over their head and learning to program. 

And all he/she wanted was a radio.

Also where there are choices, Murphy's law: IF there are two choices the selected one will be
wrong.  

Allison

Re: Upgrades and backward compatibility

MadRadioModder
 

Actually it’s a whole lot easier than that.  v5 #2 IF is 11 MHz whereas the v4 boards and earlier use 12 MHz.  If you select the wrong software version you won’t hear anything.

 

MRM

 

 

From: BITX20@groups.io [mailto:BITX20@groups.io] On Behalf Of Jerry Gaffke via Groups.Io
Sent: Monday, February 11, 2019 4:55 PM
To: BITX20@groups.io
Subject: Re: [BITX20] Upgrades and backward compatibility

 

Too late.
And not that big of a deal anyway.

Has not been much of a problem for Bitx40 vs v3/v4
And won't be much of a problem for v3/v4 vs v5.

I could imagine ways of designing the Bitx40, v3,v4 and v5 such that they could be distinguished. 
Perhaps light pullups/pulldowns on TXA,B,C (and have them drive FET,'s, not 2n3904's).
But that's more trouble than it's worth, and would have required knowing  back in 2016
that the uBitx would be coming along.

Jerry


On Mon, Feb 11, 2019 at 02:36 PM, Arv Evans wrote:

Looking back at some of the commercial systems that I have worked on over the years, it

comes to mind that some of these systems were able to read specific voltage or ground points

on motherboards and daughter boards to determine what version they were working with.

In the uBITX, BITX-40, etc. we have both the Raduino and main board to consider, and

possible some other boards and variants in hardware configurations. 

 


Virus-free. www.avg.com

--

…_. _._

Re: Upgrades and backward compatibility

Jerry Gaffke
 

Your assuming everything works when the correct software is selected.


On Mon, Feb 11, 2019 at 03:06 PM, MadRadioModder wrote:

Actually it’s a whole lot easier than that.  v5 #2 IF is 11 MHz whereas the v4 boards and earlier use 12 MHz.  If you select the wrong software version you won’t hear anything.

 

Re: Upgrades and backward compatibility

Curt
 

Team

stepping back here, the paradigm is getting a rig that isn't made in a conventional factory.  if we possess a v3 or v4, let's enjoy the ride with the blessings that already exist of lots of options for firmware and hardware.  its a cool rig even with stock firmware and the LCD display - for many in the world that use these rigs - they are content with that. 

the folk that develop the add-on firmware are people, not genies, nor folk we have under contract.  Let's hope for some continued v3 and v4 support - but let's not take them to task for their voluntary efforts. 

good question but not one to worry with.  operate the rig with however you have it configured,

let's also respect the perspectives and economics of folk using these nice rigs around the globe.  what could be better, an affordable path to the airwaves with a lot of technical opportunity also. 

73 Curt