Topics

Master file for Bitx40 Opinion by W8LM

Lawrence Macionski <am_fm_radio@...>
 

I know my opinion is of little value, as I lost the election for the ultimate supreme ruler of the universe... however...

I would appreciate and I'm sure Jack K8TEE would agree, that we do need a bullet proof, battle ready set of files-instructions.. of a tested "approved" release of the arduino sketch.  Something we can revert back to.. should we crash and burn because of cockpit error or following someones "latest and greatest" to only find a typo or some other missing link. I need a place I can go to and say-- all this is rock solid.. (for instance the wiring pictorial at HFSIGS.COM shows the tuning pot for the Radino without the capacitor added. It does NOT state if the wiring is viewed from the front or back of the pot.)

I follow the blog daily and have not touched my BITX40 in 2 weeks because of required duties elsewhere. I am not sure if the calibration fix is "official" along with the diodes on the relays, and the cap to reduce 2nd harmonic... I know about them, I do not know if they are "official" or if now part of the build or not, and if not, why not? After all, not all of us are PhD's, or have been in ham radio 50 years, or have extensive backgrounds in blowing smoke and flashing mirrors. Does today's recipient of the kit need to read every blog for 6 months to come up to speed?

I guess this buck needs passed to Farhan as leader--(Hail leader) with our support. Perhaps even a volunteer or two to off load some duties. Having seen the same thing happen elsewhere - namely Simon Brown and Ham Radio Deluxe -it started as a simple meager PSK31 -Yaesu FT817 combination and turned into a commercial business that requires daily support of 4-10 people.. I know at one time Simon was overwhelmed. he must of.

So Farhan, will there be a defacto standard repository of official released BITX 40.??? If so, let all of us know. So we can promote it to off load some of the daily inquiries you get.  I don't think it should be in this blog, but this blog should reference it as needed. Probably needs to be at HFSIGS.com. Advise?

Larry W8LM

ARRL Life Member -licensed 50 years.

Past President, 2 terms, VFW post 3115 Amateur Radio Club, W0VFW -Wichita, Kansas




Jonathan Peakall
 

Well, you got more votes than I did but...

I agree. As a new user I am struggling to catch up on what the current state is of hardware and software. I also realize that for the  low price of the kit that we are already getting a lot for the money and that support isn't cheap. I'm not  big fan of groups.io either, but again it takes time and money to maintain a forum. I don't think we need full hand holding, this is supposed to be an experimenters rig. But it is a little chaotic right now.

Jonathan KK6RPX







On 3/21/2017 7:04 AM, Lawrence Macionski via Groups.Io wrote:

I know my opinion is of little value, as I lost the election for the ultimate supreme ruler of the universe... however...

I would appreciate and I'm sure Jack K8TEE would agree, that we do need a bullet proof, battle ready set of files-instructions.. of a tested "approved" release of the arduino sketch.  Something we can revert back to.. should we crash and burn because of cockpit error or following someones "latest and greatest" to only find a typo or some other missing link. I need a place I can go to and say-- all this is rock solid.. (for instance the wiring pictorial at HFSIGS.COM shows the tuning pot for the Radino without the capacitor added. It does NOT state if the wiring is viewed from the front or back of the pot.)

I follow the blog daily and have not touched my BITX40 in 2 weeks because of required duties elsewhere. I am not sure if the calibration fix is "official" along with the diodes on the relays, and the cap to reduce 2nd harmonic... I know about them, I do not know if they are "official" or if now part of the build or not, and if not, why not? After all, not all of us are PhD's, or have been in ham radio 50 years, or have extensive backgrounds in blowing smoke and flashing mirrors. Does today's recipient of the kit need to read every blog for 6 months to come up to speed?

I guess this buck needs passed to Farhan as leader--(Hail leader) with our support. Perhaps even a volunteer or two to off load some duties. Having seen the same thing happen elsewhere - namely Simon Brown and Ham Radio Deluxe -it started as a simple meager PSK31 -Yaesu FT817 combination and turned into a commercial business that requires daily support of 4-10 people.. I know at one time Simon was overwhelmed. he must of.

So Farhan, will there be a defacto standard repository of official released BITX 40.??? If so, let all of us know. So we can promote it to off load some of the daily inquiries you get.  I don't think it should be in this blog, but this blog should reference it as needed. Probably needs to be at HFSIGS.com. Advise?

Larry W8LM

ARRL Life Member -licensed 50 years.

Past President, 2 terms, VFW post 3115 Amateur Radio Club, W0VFW -Wichita, Kansas





Ken
 

How about using the Wiki that was setup?

73

Ken VA3ABN

On Tue, Mar 21, 2017 at 10:23 AM, Jonathan Peakall <jpeakall@...> wrote:
Well, you got more votes than I did but...

I agree. As a new user I am struggling to catch up on what the current state is of hardware and software. I also realize that for the  low price of the kit that we are already getting a lot for the money and that support isn't cheap. I'm not  big fan of groups.io either, but again it takes time and money to maintain a forum. I don't think we need full hand holding, this is supposed to be an experimenters rig. But it is a little chaotic right now.

Jonathan KK6RPX







On 3/21/2017 7:04 AM, Lawrence Macionski via Groups.Io wrote:

I know my opinion is of little value, as I lost the election for the ultimate supreme ruler of the universe... however...

I would appreciate and I'm sure Jack K8TEE would agree, that we do need a bullet proof, battle ready set of files-instructions.. of a tested "approved" release of the arduino sketch.  Something we can revert back to.. should we crash and burn because of cockpit error or following someones "latest and greatest" to only find a typo or some other missing link. I need a place I can go to and say-- all this is rock solid.. (for instance the wiring pictorial at HFSIGS.COM shows the tuning pot for the Radino without the capacitor added. It does NOT state if the wiring is viewed from the front or back of the pot.)

I follow the blog daily and have not touched my BITX40 in 2 weeks because of required duties elsewhere. I am not sure if the calibration fix is "official" along with the diodes on the relays, and the cap to reduce 2nd harmonic... I know about them, I do not know if they are "official" or if now part of the build or not, and if not, why not? After all, not all of us are PhD's, or have been in ham radio 50 years, or have extensive backgrounds in blowing smoke and flashing mirrors. Does today's recipient of the kit need to read every blog for 6 months to come up to speed?

I guess this buck needs passed to Farhan as leader--(Hail leader) with our support. Perhaps even a volunteer or two to off load some duties. Having seen the same thing happen elsewhere - namely Simon Brown and Ham Radio Deluxe -it started as a simple meager PSK31 -Yaesu FT817 combination and turned into a commercial business that requires daily support of 4-10 people.. I know at one time Simon was overwhelmed. he must of.

So Farhan, will there be a defacto standard repository of official released BITX 40.??? If so, let all of us know. So we can promote it to off load some of the daily inquiries you get.  I don't think it should be in this blog, but this blog should reference it as needed. Probably needs to be at HFSIGS.com. Advise?

Larry W8LM

ARRL Life Member -licensed 50 years.

Past President, 2 terms, VFW post 3115 Amateur Radio Club, W0VFW -Wichita, Kansas






Jack Purdum <econjack@...>
 

All:

I personally think Farhan should have absolute control over the "official" Raduino code. This could be placed somewhere (github?) where only he can alter the source code. Others can download it, but no uploads would be allowed other than by Farhan. 

Others who add features or otherwise modify the "official" code need to place their call somewhere in the modified file (e.g., RaduinoSourceW8TEE.ino) and then upload it to the Files section of the group web site. A small TXT file should be uploaded with the new file that explains what features/mods are in the file. A brief summary of those changes could also be in a comment within the file itself. I would further suggest that we adopt the convention of placing the download site (URL) for any required libraries that are not part of the standard Arduino IDE as part of the #include statement:

    #include <MCUFRIEND_kbv.h>    // https://github.com/prenticedavid/MCUFRIEND_kbv

This would help avoid the problems associated with libraries that are not part of the IDE. It then becomes the responsibility of the user to locate those additional libraries and install them properly in the IDE. I have made a few posts on how new libraries should be installed. I have also uploaded a file that tells how to download, install, and test the IDE.

Now, the complications that I envision. Someone likes some of the features in a new file (e.g., RaduinoSourceW8TEE.ino) but then wants to add their own feature set to that file. How do we show the lineage of the code? One way is to append the current person's call to the base file being modified (e.g., RaduinoSourceW8TEE-W6DQ.ino). That will quickly get out of hand and make for unwieldy file names. Instead, how about adding a new comment line at the top of the source file that can be added to, and change the Version number in the file name:

    RaduinoSource-Ver01.ino
        /* This file is based on the original Raduino source code with additions by W8TEE--March 21, 2017. The major changes 
            include: TFT display, Fast Tune, etc.
        */ 

Now Dennis comes along and modifies that file:

    RaduinoSource-Ver02.ino
        /* This file adds to the Ver01 file by W8TEE by W6DQ, April 10, 2017. The major changes are: CW/SSB switch, keyer, and 
            AGC. */
        /* This file is based on the original Raduino source code with additions by W8TEE--March 21, 2017. The major changes 
            include: TFT display, Fast Tune, etc.
        */ 

This makes it easy to see the lineage of the source file without extending the name. If we preserve each source file (e.g., Ver01 even if a later version exists), it would allow anyone to "backup" to an earlier version if they wish. This would also make it possible to run a file compare program to see exactly what the differences are between two files.

I'm sure others have ideas on the mechanics of how we should do this. Right now, I think the important thing is that we agree there needs to be some simple form of source code control.

Jack, W8TEE


From: Ken <chase8043@...>
To: BITX20@groups.io
Sent: Tuesday, March 21, 2017 10:28 AM
Subject: Re: [BITX20] Master file for Bitx40 Opinion by W8LM

How about using the Wiki that was setup?

73

Ken VA3ABN

On Tue, Mar 21, 2017 at 10:23 AM, Jonathan Peakall <jpeakall@...> wrote:
Well, you got more votes than I did but...

I agree. As a new user I am struggling to catch up on what the current state is of hardware and software. I also realize that for the  low price of the kit that we are already getting a lot for the money and that support isn't cheap. I'm not  big fan of groups.io either, but again it takes time and money to maintain a forum. I don't think we need full hand holding, this is supposed to be an experimenters rig. But it is a little chaotic right now.

Jonathan KK6RPX







On 3/21/2017 7:04 AM, Lawrence Macionski via Groups.Io wrote:
I know my opinion is of little value, as I lost the election for the ultimate supreme ruler of the universe... however...
I would appreciate and I'm sure Jack K8TEE would agree, that we do need a bullet proof, battle ready set of files-instructions.. of a tested "approved" release of the arduino sketch.  Something we can revert back to.. should we crash and burn because of cockpit error or following someones "latest and greatest" to only find a typo or some other missing link. I need a place I can go to and say-- all this is rock solid.. (for instance the wiring pictorial at HFSIGS.COM shows the tuning pot for the Radino without the capacitor added. It does NOT state if the wiring is viewed from the front or back of the pot.)
I follow the blog daily and have not touched my BITX40 in 2 weeks because of required duties elsewhere. I am not sure if the calibration fix is "official" along with the diodes on the relays, and the cap to reduce 2nd harmonic... I know about them, I do not know if they are "official" or if now part of the build or not, and if not, why not? After all, not all of us are PhD's, or have been in ham radio 50 years, or have extensive backgrounds in blowing smoke and flashing mirrors. Does today's recipient of the kit need to read every blog for 6 months to come up to speed?
I guess this buck needs passed to Farhan as leader--(Hail leader) with our support. Perhaps even a volunteer or two to off load some duties. Having seen the same thing happen elsewhere - namely Simon Brown and Ham Radio Deluxe -it started as a simple meager PSK31 -Yaesu FT817 combination and turned into a commercial business that requires daily support of 4-10 people.. I know at one time Simon was overwhelmed. he must of.
So Farhan, will there be a defacto standard repository of official released BITX 40.??? If so, let all of us know. So we can promote it to off load some of the daily inquiries you get.  I don't think it should be in this blog, but this blog should reference it as needed. Probably needs to be at HFSIGS.com. Advise?
Larry W8LM
ARRL Life Member -licensed 50 years.
Past President, 2 terms, VFW post 3115 Amateur Radio Club, W0VFW -Wichita, Kansas







James Lynes
 

Deja Vu all over again... The Ten Tec Rebel forum had the same issues...

My two cents... Here's the header I use on my Arduino/C/Perl/etc source files...


/*
 * Name:                RaduinoSSB.ino
 * Author:               Ashhar Farhan, VU2ESE, et. al.
 * Version:             1.0.2
 * Created:             March 10, 2017 from post #23016 by Allard PE1NWL BITX20@groups.io
 * Modified By:        James M. Lynes, Jr.(KE4MIQ), jmlynesjr@...
 * Last Modified:     March 14, 2017
 * Environment       Arduino Nano w/ATmega328
 * Change Log:       3/10/17   - Installed Allard's file
 *                                            - Fixes Calibration Routine
 *                                            - Fixes Subrouting calls to V2 of si5351 library
 *                                            - Fixes Tuning Flutter
 *                                            - Add this header block
 *                                            - Clean compile
 *                             3/12/17   - Create SSB only version
 *                                            - Begin by removing unused code, like CW mode, button processing
 *                                            - Rename printLine to lcdprintLine, reduce confusion vs Serial.print()
 *                                            - Updated LCD & Serial messages
 *                             3/13/17   - Update various comments
 *                             3/14/17   - Update more comments, remove more unused code
 * Description:         Operating code for the BITX40, 40M Transceiver Kit from HFSIGS.COM
 * Notes:        
 *

Michael Davis <maddmd818@...>
 

One member's advice to take your time, evidently is not being heeded by many. The old adage "measure twice, cut once" sure applies here. Read five times solder once, if you are lucky. The potentiometer, for example, is shown in a photo, in place, with the correctly colored wires attached. The other drawing of the tuning pot is depicted from the shaft end, but not obvious. I'm not sure if the "wire it" section has been changed at all recently. The directions lead one to believe that the Bitx can be built using only the first photo/drawing page. Maybe on your second build or with much luck or experience, but not most of us. Many of us remember checking the little block on a Heathkit or Eico kit, as we connected each wire or component, but not soldering until the directions said so. The Bitx requires more reading ahead 5 times, to get the jist of what is next. Then there is the color codes...what color codes?

Sent from Mike's iPad WA1MAD

Jerry Gaffke
 

>  Farhan should have absolute control over the "official" Raduino code.

Should.  But he seems to have other stuff on his plate.  I don't think managing Raduino code is his thing.  As I recall, he was previously asking somebody with a fix to just go ahead an push it up into github.  Perhaps we need somebody else here to take over that job.  (Hi Jack!)

 

>    RaduinoSource-Ver02.ino
>        /* This file adds to the Ver01 file by W8TEE by W6DQ, April 10, 2017. The major changes are: CW/SSB switch, keyer, and 
>            AGC. */
>        /* This file is based on the original Raduino source code with additions by W8TEE--March 21, 2017. The major changes 
>            include: TFT display, Fast Tune, etc.
>        */ 

>  I'm sure others have ideas on the mechanics of how we should do this.

Yup.  I suggest code get placed in the files section under your call.  Give the file an arbitrary name, perhaps W8TEE/FixDualVfo00.ino
Note the final 00 there, that's the revision number.  If Jack sees the inevitable bug, he creates a new file  FixDualVfo01.ino, but leaves the rev 00 file as it was since somebody may have started with FixDualVfo00.ino when creating their code.  Give the entire path name for the new file at the start of your comment that describes the file.    If it's just a single file, then make it the ino file.  If it's multiple files, give the directory name.  So, to badly hack Jack's example:

// Files/KE7ER/FlutterFix00:  March 21, 2017   Added code to reduce noise from tuning pot.  

// Files/W8TEE/FixDualVfo00:  Jan 31, 2017    Fixed Ashhar's original code to use function switch to select VFO A or B  

//  https://github.com/andrewbeard/bitx40    Ashhar's original Raduino code as posted to github

I've never messed with git (but should).  That final line should include some way of getting the correct version.  If what you have to say needs more than one line, then indent lines or perhaps add a blank line.  Use any valid comment scheme you are comfortable with.

I fully agree with Jack's suggestion that any library used should have a comment right there in the source code telling you where to find the library.  And tell us the  revision number of the library you used. 

>  A small TXT file should be uploaded with the new file that explains what features/mods are in the file. 

Assuming most of these will be a single *.ino file, I'd tend to make that a comment at the top of the source code, just below the revision control stuff.  If your code is multiple files, then make it a subdirectory under your call in the files section.

Jerry, KE7ER 


On Tue, Mar 21, 2017 at 08:21 am, Jack Purdum wrote:

All:

I personally think Farhan should have absolute control over the "official" Raduino code. This could be placed somewhere (github?) where only he can alter the source code. Others can download it, but no uploads would be allowed other than by Farhan. 

Others who add features or otherwise modify the "official" code need to place their call somewhere in the modified file (e.g., RaduinoSourceW8TEE.ino) and then upload it to the Files section of the group web site. A small TXT file should be uploaded with the new file that explains what features/mods are in the file. A brief summary of those changes could also be in a comment within the file itself. I would further suggest that we adopt the convention of placing the download site (URL) for any required libraries that are not part of the standard Arduino IDE as part of the #include statement:

    #include <MCUFRIEND_kbv.h>    // https://github.com/prenticedavid/MCUFRIEND_kbv

This would help avoid the problems associated with libraries that are not part of the IDE. It then becomes the responsibility of the user to locate those additional libraries and install them properly in the IDE. I have made a few posts on how new libraries should be installed. I have also uploaded a file that tells how to download, install, and test the IDE.

Now, the complications that I envision. Someone likes some of the features in a new file (e.g., RaduinoSourceW8TEE.ino) but then wants to add their own feature set to that file. How do we show the lineage of the code? One way is to append the current person's call to the base file being modified (e.g., RaduinoSourceW8TEE-W6DQ.ino). That will quickly get out of hand and make for unwieldy file names. Instead, how about adding a new comment line at the top of the source file that can be added to, and change the Version number in the file name:

    RaduinoSource-Ver01.ino
        /* This file is based on the original Raduino source code with additions by W8TEE--March 21, 2017. The major changes 
            include: TFT display, Fast Tune, etc.
        */ 

Now Dennis comes along and modifies that file:

    RaduinoSource-Ver02.ino
        /* This file adds to the Ver01 file by W8TEE by W6DQ, April 10, 2017. The major changes are: CW/SSB switch, keyer, and 
            AGC. */
        /* This file is based on the original Raduino source code with additions by W8TEE--March 21, 2017. The major changes 
            include: TFT display, Fast Tune, etc.
        */ 

This makes it easy to see the lineage of the source file without extending the name. If we preserve each source file (e.g., Ver01 even if a later version exists), it would allow anyone to "backup" to an earlier version if they wish. This would also make it possible to run a file compare program to see exactly what the differences are between two files.

I'm sure others have ideas on the mechanics of how we should do this. Right now, I think the important thing is that we agree there needs to be some simple form of source code control.

Jack, W8TEE

 

K5ESS
 

I started a WIKI page for "Retrieving the Raduino Code"  so now I need to know the link to Farhan's code that is under his control. 

Mike

K5ESS

Jack Purdum <econjack@...>
 

I think this is workable. See comments below:

Jack, W8TEE


From: Jerry Gaffke via Groups.Io <jgaffke@...>
To: BITX20@groups.io
Sent: Tuesday, March 21, 2017 10:52 PM
Subject: Re: [BITX20] Master file for Bitx40 Opinion by W8LM

>  Farhan should have absolute control over the "official" Raduino code.
Should.  But he seems to have other stuff on his plate.  I don't think managing Raduino code is his thing.  As I recall, he was previously asking somebody with a fix to just go ahead an push it up into github.  Perhaps we need somebody else here to take over that job.  (Hi Jack!) This probably isn't necessary given the way you've suggested we do this. If people follow the process Jerry described here, it should work without guidance. (Of course, since I love this kind of stuff, so I'll probably be watching things pretty closely anyway.)
 
>    RaduinoSource-Ver02.ino
>        /* This file adds to the Ver01 file by W8TEE by W6DQ, April 10, 2017. The major changes are: CW/SSB switch, keyer, and 
>            AGC. */
>        /* This file is based on the original Raduino source code with additions by W8TEE--March 21, 2017. The major changes 
>            include: TFT display, Fast Tune, etc.
>        */ 

>  I'm sure others have ideas on the mechanics of how we should do this.

Yup.  I suggest code get placed in the files section under your call. This is a good idea, since it has a lineage of who is doing what. The problem comes when someone finds a code in my file. At that point, what should be done is the person who finds the bug notifies me about the bug, I fix it, change the Version number with a comment in the source file describing the bug and how it was fixed using style similar to what Jerry describes below. If we can do that, this will work.  Give the file an arbitrary name, perhaps W8TEE/FixDualVfo00.ino
Note the final 00 there, that's the revision number.  If Jack sees the inevitable bug, he creates a new file  FixDualVfo01.ino, but leaves the rev 00 file as it was since somebody may have started with FixDualVfo00.ino when creating their code. This process is important: Leave the original 00 file UNCHANGED. Make the changes to a copy of the original file, but increase the Version number. It's important to be able to go back to the state of the file prior to the bug fix. Give the entire path name for the new file at the start of your comment that describes the file.    If it's just a single file, then make it the ino file.  If it's multiple files, give the directory name.  So, to badly hack Jack's example:

// Files/KE7ER/FlutterFix00:  March 21, 2017   Added code to reduce noise from tuning pot.  

// Files/W8TEE/FixDualVfo00:  Jan 31, 2017    Fixed Ashhar's original code to use function switch to select VFO A or B  

//  https://github.com/andrewbeard/bitx40    Ashhar's original Raduino code as posted to github

I've never messed with git (but should).  That final line should include some way of getting the correct version.  If what you have to say needs more than one line, then indent lines or perhaps add a blank line.  Use any valid comment scheme you are comfortable with.

I fully agree with Jack's suggestion that any library used should have a comment right there in the source code telling you where to find the library.  And tell us the  revision number of the library you used. 

>  A small TXT file should be uploaded with the new file that explains what features/mods are in the file. 
The only reason I made this suggestion was in case multiple people wanted to know what's changed in the file without actually loading the file. (I'm assuming the TXT file would be shorter.) I can live without this.
Assuming most of these will be a single *.ino file, I'd tend to make that a comment at the top of the source code, just below the revision control stuff.  If your code is multiple files, then make it a subdirectory under your call in the files section.

Jerry, KE7ER 


On Tue, Mar 21, 2017 at 08:21 am, Jack Purdum wrote:
All:

I personally think Farhan should have absolute control over the "official" Raduino code. This could be placed somewhere (github?) where only he can alter the source code. Others can download it, but no uploads would be allowed other than by Farhan. 

Others who add features or otherwise modify the "official" code need to place their call somewhere in the modified file (e.g., RaduinoSourceW8TEE.ino) and then upload it to the Files section of the group web site. A small TXT file should be uploaded with the new file that explains what features/mods are in the file. A brief summary of those changes could also be in a comment within the file itself. I would further suggest that we adopt the convention of placing the download site (URL) for any required libraries that are not part of the standard Arduino IDE as part of the #include statement:

    #include <MCUFRIEND_kbv.h>    // https://github.com/prenticedavid/MCUFRIEND_kbv

This would help avoid the problems associated with libraries that are not part of the IDE. It then becomes the responsibility of the user to locate those additional libraries and install them properly in the IDE. I have made a few posts on how new libraries should be installed. I have also uploaded a file that tells how to download, install, and test the IDE.

Now, the complications that I envision. Someone likes some of the features in a new file (e.g., RaduinoSourceW8TEE.ino) but then wants to add their own feature set to that file. How do we show the lineage of the code? One way is to append the current person's call to the base file being modified (e.g., RaduinoSourceW8TEE-W6DQ.ino). That will quickly get out of hand and make for unwieldy file names. Instead, how about adding a new comment line at the top of the source file that can be added to, and change the Version number in the file name:

    RaduinoSource-Ver01.ino
        /* This file is based on the original Raduino source code with additions by W8TEE--March 21, 2017. The major changes 
            include: TFT display, Fast Tune, etc.
        */ 

Now Dennis comes along and modifies that file:

    RaduinoSource-Ver02.ino
        /* This file adds to the Ver01 file by W8TEE by W6DQ, April 10, 2017. The major changes are: CW/SSB switch, keyer, and 
            AGC. */
        /* This file is based on the original Raduino source code with additions by W8TEE--March 21, 2017. The major changes 
            include: TFT display, Fast Tune, etc.
        */ 

This makes it easy to see the lineage of the source file without extending the name. If we preserve each source file (e.g., Ver01 even if a later version exists), it would allow anyone to "backup" to an earlier version if they wish. This would also make it possible to run a file compare program to see exactly what the differences are between two files.

I'm sure others have ideas on the mechanics of how we should do this. Right now, I think the important thing is that we agree there needs to be some simple form of source code control.

Jack, W8TEE