Broken Si570 code

[ghost]

I'm about to post a updates to the mcHF code with some additional features, but I notice that between my last, posted version (0.0.219.22, I believe) and the version 0.0.219.24 posted here, the Si570 tuning code has been broken.

Here is how I can cause it to most easily show up:

• Select 10 kHz tuning steps.
• Tune up and down over a 75-150 kHz range.

When it fails, you will start hearing loud clicks. When it does this, you will find the receiver dead. On my transceiver it seems to occur in specific frequency bands, such as between approximately 6.95 and 7.13 MHz and between around 3.63 and 3.74.

It may take a minute or two of tuning around for this to start happening, and if one tunes very far outside the "broken" range, it seems to fix itself for a short time.

This would appear to be related to the "coarse retune" portion of the tuning algorithm - maybe the synthesizer not un-muting or, possibly, contention on the serial bus causing some tuning information to be lost.

Any ideas?

Thanks,

Clint KA7OEI

[df8oe]

Hello Clint,

its not the code itself but a few definitions. I have had tested tuning behaviour on 5 mcHFs and want to investigate working ranges of different SI570. Therefore I set the borders larger to see the hadware-related max/min.

Take a look at ui_si570.h at the following lines:

define SI570_MIN_FREQ 1000000 // 7.2=1.8 MHz

define SI570_MAX_FREQ 200000000 // 128=32 Mhz

define FDCO_MAX 5870

define FDCO_MIN 4650

• this are the values that are actually set -

and set them to the values of 219.22:

define SI570_MIN_FREQ 7200000 // 7.2=1.8 MHz

define SI570_MAX_FREQ 128000000 // 128=32 Mhz

define FDCO_MAX 5670

define FDCO_MIN 4850

Because this does not affect normal operation I haven't reset them - sorry.

Please let me know if this fixes error for you. Thats the only part in si570 code I touched.

vy 73 Andreas

[df8oe]

I have set internal VCO borders to values as before and output to 7.2/160 MHz and committed to master, devel and mchf_git_base_20151009. I deleted "rc"-branch because of it is without any use.

vy 73 Andreas

[df8oe]

Here another information about git works:

https://www.atlassian.com/git/tutorials/setting-up-a-repository

vy 73 Andreas

[ghost]

Thank you for the information, Andreas.

About the range: I figured that it was something like that. When it comes to using the Si570 as a synthesizer in a radio, a lot of people have lost a lot of hair to make it work correctly. The biggest issue with the "old" tuning algorithm (aside from being able to accept "odd" Si570 variants, perhaps) is that it does a coarse retune at exactly the same frequency each time. I don't know if you have had a chance to look at the Dutch ham's Atmel code (open source) to which I referred a few weeks ago: That appears to be very solid and well-behaved and could serve as "inspiration." (Chris once told me that getting the Si570 to work properly was one of the most difficult aspects of his work on the mcHF - and I'm not surprised!)

For example, if the coarse retune occurred at 7.116253 MHz (a number I pulled out of the air) every time you tuned above or below this frequency the coarse retune would occur. I have other Si570 implementations that do not do this, but rather have a bit of hysteresis

• although I'm not sure how much, but 3-5 kHz (+/-1.5-2.5) would be adequate for tuning through the passband of about any signal found on HF.

I mention this since I was thinking in the back of my mind about a way to implement synchronous AM without using much processor power and using the good tuning resolution of the Si570 would be reasonable - but if one was unlucky enough to have the SAM loop constantly cross that boundary that would... well, you can figure it out!

---

I am about to push (and pull) some new code: I'll post the .bin first and then try updating the git. If that fails, I'll place it on a server where you can get it in a timely fashion so that you can pull it into the git - but I really do need to get the hang of this thing. Just so you know, I happen to be using the Windows GUI-based github interface and it just doesn't seem to do the same thing every time - either that, or there is something subtle that I'm missing. It does have a command-line interface and I may have to revert to that, if all else fails.

73,

Clint KA7OEI

On 10/28/2015 5:32 AM, DF8OE wrote:

Here another information about git works:

https://www.atlassian.com/git/tutorials/setting-up-a-repository

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-151809498.

[DD4WH]

Hi Clint, hi Andreas,

the Arduino community uses the excellent Si570 driver by Farhan, modified by Thomas Sarlandie and by Jeff Whitlatch. It works perfectly in many hundreds of single-conversion superhet rigs (the Minima, I have one at home, it was one of my favourite radios until I ruined the audio amp ;-)). I remember there were numerous discussions and optimizations of the code, because they had exactly the same problems with the Si570 drivers as the mcHF. That seems to be resolved now and it really works well without clicks, holes in the frequency spectrum etc. The code is MIT licensed, whatever that means.

http://ko7m.blogspot.de/2014/08/bug-found-in-si570-code-for-minima.html

https://github.com/ko7m/Si570

https://github.com/sarfata/radiono/blob/merge-wa0uwh/radiono/Si570.cpp

Maybe that helps resolve the problems with the Si570, although I do not know how much work it will be to port the code the STM32F4 family.

73 de Frank DD4WH

[df8oe]

Hello Clint,

when I investigated code of SI570 and tested out tuning behaviour below and ybove specs I decided to make a hardware-solution for 160m and lower and for 4 and 6m. It is not reliable to use SI570 so wide outside specs.... +++++ There is a GUI for git on Linux, too. But it is working only rudimentarily and some important functions are missing complete. Because of git is very mighty and there are many slightly different commands no GUI exits (for Linux) that works in all functions. I think that is the same as for Windows. There is no reason why not to port it to both systems if it exists for one of them. So I am sure you must use CLI, and you will only need a handful commands for working. I start a litle howto now (all working on command line)

Clonig remote sources to local: cd git clone http://github.com/df8oe/mchf-github.git

Now the master branch is on your local drive. Change to git working folder with: cd mchf-git

now you can look what branches exist with git branch -a

local branches are at top of the list, the active one has an asterisk leading, remote branches are red.

You can switch to another branch with git checkout (e.g. mchf_git_base_20151009)

...and test your new setting with git branch -a

You will see that every branch you "checkout'd" now is available locally. If you only want information about the active branch you can call git status instead of git branch -a

The point a Windows-user has huge problems is: when you checkout to another branch, the sources are corrected immediately!! You press enter and half a second later the source of the now active branch is lying under mchf-eclipse. If you checkout to another branch, same occurs an now the sources of the new branch are under mchf-eclipse, the sources of the former active branch are NOT LOST. The differences are managed by git and only the differences where coreected by switching.

OK - lets start a programming-walk... You checkout to the branch you want to work on (normally your mchf_git_base_20151009). Now you do your work. When you have finished, you must tell git that you have finished.

First you must change directory to mchf-git. Located in this directory you type git add mchf-eclipse

This adds complete folder with surces to the database of git. Git now analyzes code-diffs and stores it internally (not important how it works - it works, that's all you mut know).

Next step is preparing git for building the diffs - that is called "committing":

git commit -m "here is your comment"

...always staying in the folder mchf-git. The comment is for other users - they can see whats the reason for this commit and therefor for a better understanding.

At this point you have added the changes to your local git-database and building the files for transmitting - but they are only locally on your computer. If you want to export the new changes to github, you must type

git push origin mchf_git_base_20151009 (or any other branch you want to work on)

git now asks for your passphrase and if it is correct the deltas are transferred.

If you want to change to another branch proceed as on top of my howto. if you checkout to another branch you immediately see the code of this branch - don't worry - your work is not lost :) If you checkout to the branch you worked before and where you have done the changes they are present after ckeckout.

git manages all changes, differences, and can show them to other coders. And you do not waste time in putting code lines from other coders in your code - that can git do for you automatically (that will be subject of another howto).

I hope it helps.

I agree Clint - you are the most active developer and most of the code that exists is coded by you. It is very important that you can do these steps by yourself.

vy 73 Andreas

[df8oe]

Hallo Frank,

porting this to STM is not very difficult. And MIT license allows using the code for our project. Many thanks for your hint!

vy 73 Andreas

[ghost]

Hi Andreas,

The problem turned out to be the "FDCO_MIN" and "FDCO_MAX" settings.

It would appear that these parameters differ from unit-to-unit. I'm guessing that some Si570 drivers will start out with "safe" values and then "learn" the new range for the specific device in use, revising the limits if a tune fails, for example - possibly even expanding the range by trial and error - either that, or there might be a start-up function that is called that does this.

---

As for tuning an Si570 "without clicks" of any kind, I don't believe that this is possible, at least given my understanding of how the Si570 works, but it may be minimized. At the moment the mcHF code does minimize clicks if one is tuning in small steps (1 kHz or so) simply by "testing the waters" of the next frequency and muting the receiver chain briefly if a coarse retune will be required.

73,

Clint KA7OEI

On 10/28/2015 6:20 PM, Clint Turner wrote:

Thank you for the information, Andreas.

About the range: I figured that it was something like that. When it comes to using the Si570 as a synthesizer in a radio, a lot of people have lost a lot of hair to make it work correctly. The biggest issue with the "old" tuning algorithm (aside from being able to accept "odd" Si570 variants, perhaps) is that it does a coarse retune at exactly the same frequency each time. I don't know if you have had a chance to look at the Dutch ham's Atmel code (open source) to which I referred a few weeks ago: That appears to be very solid and well-behaved and could serve as "inspiration." (Chris once told me that getting the Si570 to work properly was one of the most difficult aspects of his work on the mcHF - and I'm not surprised!)

For example, if the coarse retune occurred at 7.116253 MHz (a number I pulled out of the air) every time you tuned above or below this frequency the coarse retune would occur. I have other Si570 implementations that do not do this, but rather have a bit of hysteresis - although I'm not sure how much, but 3-5 kHz (+/-1.5-2.5) would be adequate for tuning through the passband of about any signal found on HF.

I mention this since I was thinking in the back of my mind about a way to implement synchronous AM without using much processor power and using the good tuning resolution of the Si570 would be reasonable - but if one was unlucky enough to have the SAM loop constantly cross that boundary that would... well, you can figure it out!

---

I am about to push (and pull) some new code: I'll post the .bin first and then try updating the git. If that fails, I'll place it on a server where you can get it in a timely fashion so that you can pull it into the git - but I really do need to get the hang of this thing. Just so you know, I happen to be using the Windows GUI-based github interface and it just doesn't seem to do the same thing every time - either that, or there is something subtle that I'm missing. It does have a command-line interface and I may have to revert to that, if all else fails.

73,

Clint KA7OEI

On 10/28/2015 5:32 AM, DF8OE wrote:

Here another information about git works:

https://www.atlassian.com/git/tutorials/setting-up-a-repository

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-151809498.

[df8oe]

Hello Clint,

I have had a look at the code from the link DD4WH posted some antries above. It is slightly different from ours - maybe we can test out and find what is working better... But I do not think this has high priority.

I am working on implementing serial EEPROM. Because of I am working on touchscreen function, too I need two free GPIOs for CS and IRQ from tocuscreen SPI. The easiest way is to fit EEPROM not o an "own i2c" but on the existing. I have done this and everything works fine. So I decided to use the two lines of second i2c for touchscreen and test presence of serial EEPROM on first i2c. But code is locally at this moment because of it is pre-alpha :)

Let us work out if you can commit and push changes you have made to GitHub - to YOUR branch. Then it will be my work to merge it together to "the rest". If this all works it will be a great step to normal developing - I hope you are successful...

vy 73 Andreas

[df8oe]

Hello Clint,

many thanks for opening a new branch for 219.26. Because of this version is in "testing"-stage I will wait until major bugs are fixed and then merge it to master. It will be great if you do not open a new branch for the fixed version. Please commit and push each fix in a single step to the existing branch. So everyone can see the diffs and understand what was changed. It will be a really good idea if you commit fixes seperately because roll back is possible if you do so. It is possible to roll back a complete commit, but not parts of it.

vy 73 Andreas

[ghost]

There does not seem to be a built-in mechanism to deal with progressive versions of firmware being tested and being able to differentiate them from already-released versions.

For example, were I to make modifications to 219.26, there would be a different code version, but it would be indistinguishable by the user from the "released" 219.26 version - a situation that MUST be avoided.

The way I see it we have at least three choices:

• Ignore the problem and hope that a binary that is "in progress" doesn't get confused with other versions. In this case one would be required to name the binary itself something more useful than simply "mchf_eclipse.bin". This really should be done, anyway, and it is why all of my released binaries have included the F/W version - sometimes the date of release.)
• Add another field to indicate an "interim" version to allow differentiation.
• Re-do the version numbering. For example, "0.0.219.26" would become "0.219.26.0" with subsequent bug-fixes being "0.219.26.1", etc. The "release" would then increment to "0.219.27.0" and the process resume.

Comments?

Clint

On 10/30/2015 12:48 PM, DF8OE wrote:

Hello Clint,

many thanks for opening a new branch for 219.26. Because of this version is in "testing"-stage I will wait until major bugs are fixed and then merge it to master. It will be great if you do not open a new branch for the fixed version. Please commit and push each fix in a single step to the existing branch. So everyone can see the diffs and understand what was changed. It will be a really good idea if you commit fixes seperately because roll back is possible if you do so. It is possible to roll back a complete commit, but not parts of it.

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-152614761.

[ghost]

I have fixed the two bugs:

• Inability to turn of key beep
• "TUNE" broken on CW

Both of which were single-character errors on two lines: I'm sure that someone following along will be able to find these minor changes easily enough.

What I propose is that I push (pull, actually...) version "0.219.26.1" (and modify the "version change detect" code slightly) so that we may proceed without impediment.

Does that seem reasonable?

Clint KA7OEI

On 10/30/2015 1:07 PM, Clint Turner wrote:

There does not seem to be a built-in mechanism to deal with progressive versions of firmware being tested and being able to differentiate them from already-released versions.

For example, were I to make modifications to 219.26, there would be a different code version, but it would be indistinguishable by the user from the "released" 219.26 version - a situation that MUST be avoided.

The way I see it we have at least three choices:

• Ignore the problem and hope that a binary that is "in progress" doesn't get confused with other versions. In this case one would be required to name the binary itself something more useful than simply "mchf_eclipse.bin". This really should be done, anyway, and it is why all of my released binaries have included the F/W version - sometimes the date of release.)
• Add another field to indicate an "interim" version to allow differentiation.
• Re-do the version numbering. For example, "0.0.219.26" would become "0.219.26.0" with subsequent bug-fixes being "0.219.26.1", etc. The "release" would then increment to "0.219.27.0" and the process resume.

Comments?

Clint

On 10/30/2015 12:48 PM, DF8OE wrote:

Hello Clint,

many thanks for opening a new branch for 219.26. Because of this version is in "testing"-stage I will wait until major bugs are fixed and then merge it to master. It will be great if you do not open a new branch for the fixed version. Please commit and push each fix in a single step to the existing branch. So everyone can see the diffs and understand what was changed. It will be a really good idea if you commit fixes seperately because roll back is possible if you do so. It is possible to roll back a complete commit, but not parts of it.

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-152614761.

[df8oe]

My favorite is re-do the versioning. Versions like 219.26.0 are stable versions, all ending with a number not 0 are testing stages.

I think is ok to have one older version on GitHub - but not the whole archive. If you want this, files section of Yahoo is the place. GitHub is forward-orientatet.

If you fix some bugs in your testing branch you can start new versioning and count "1" up if a bug is fixed. No need for older versions to be accessible.

vy 73 Andreas

[df8oe]

You typed faster than me :)

YES thats ok.

vy 73 Andreas

[ghost]

Version 0.219.26.1 has now been "pushed" with the following changes:

• "Beep" enabled is fixed (you may now shut if off)
• CW "TUNE" works again
• the "version change detect" code" now detects a change of the "minor" version (the "219" part - previously "0").

This represents the known bugs in Version '26 thus far, but I'm sure that there will be more!

73,

Clint KA7OEI

On 10/30/2015 1:22 PM, DF8OE wrote:

You typed faster than me :)

YES thats ok.

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-152623836.

[ghost]

Ok, I'm a bit stumped.

In poking around on the Git I am unable to find the most recent - supposedly merged - version of the code: I find some code from 2 days ago where the serial EEPROM detection was added (branch "devel") but it is the now-obsolete 219.24 code and the contained "history" file doesn't reflect recent changes.

It would appear that I'm missing some important point: The place where I can easily find out which branch (or base, for that matter) to which changes should be pushed - I mean pulled...

I can look at the recent activity, but it appears that I must manually go into each branch and peruse each, individual commit - but this detective work still doesn't give a very good picture as to what is currently happening.

What (apparently!) obvious tool am I missing?

Clint

[df8oe]

Hello Clint,

here a short explanation about the branches:

master: the "stable" 219.24 testing: stand 219.26.4 with my improvements on bootloader and firmware devel: stand 219.26.4 with my improvements on bootloader and firmware and some code for usage of serial eeprom (not yet finished) and a new menu entry "hardware info" mchf_git_0_0_219_26: the old "master" with only your changes to 219.26.4 mchf_git_base_20151009: a "dead" branch (your first play) wip/cleanup: some code cleanings by one of our project group (not merged yet) new_cmsis: test of new cmsis

First lets define: "pull" --> you get actual code from specific branch "push" --> you send code changes to specific branch "-merge" --> you get actual code from specifc branch without loosing your chnages which occur in the meantime

It is absolutely neccessary that you get the newest "quasi-stable" code from "testing"-branch. Because of you have changed code in the meantime you CANNOT PULL (otherwise your changes are lost). First is that you commit your actual changes and push them to your mchf_git_0_0_219_26. The next steps before you change anything in code must be: -change locally to branch "testing" -pull "testing" to your local hard drive

• switch back to mchf_git_0_0_219_26 (thats now your actual code with your last changes)
• merge "testing" to your local mchf_git_0_0_219_26

GitHub has a test function on its website if merging runs automatically or if you must interact in some files. During the whole mchf-GitHub-rpcess all interactives I must do are related to files like "Readme" or "history" - not one code file. Everything worked nearly automatically.

The "devel" branch is my "playground" and you should not take it as base for pulling. Normally that should be "master" but due to many changes by you and by me it is too old to give a good base. So take "testing" - thats the best base.

vy 73 Andreas

[ghost]

Thanks for that Andreas, but...

Other than having someone who "knows" explain which branch is which, is there an actual tool that can be used to divine the information - or does this rely solely on one key person keeping a score card of which branch is supposed to be used for what? Is there a descriptor (file) maintained with that sort of information somewhere?

I ask this as I was planning to do some minor bug fixes to 0.219.26.4 and wanted to verify that I was pushing it to the correct place. I was planning to push it to "devel", but I downloaded that branch last night and it was definitely NOT 0.219.26.4, but rather it was just 0.0.219.24 with, according to the comments, your recent "EEPROM Autodetect" changes added (e.g. no FM, etc.)

I tried it twice with the "devel" branch: I "cloned" on the desktop and I also downloaded the .ZIP - both were very clearly 0.0.219.24.

I'm clearly missing something...

Clint

On 11/9/2015 11:45 PM, DF8OE wrote:

Hello Clint,

here a short explanation about the branches:

master: the "stable" 219.24 testing: stand 219.26.4 with my improvements on bootloader and firmware devel: stand 219.26.4 with my improvements on bootloader and firmware and some code for usage of serial eeprom (not yet finished) and a new menu entry "hardware info" mchf_git_0_0_219_26: the old "master" with only your changes to 219.26.4 mchf_git_base_20151009: a "dead" branch (your first play) wip/cleanup: some code cleanings by one of our project group (not merged yet) new_cmsis: test of new cmsis

First lets define: "pull" --> you get actual code from specific branch "push" --> you send code changes to specific branch "-merge" --> you get actual code from specifc branch /without loosing your chnages which occur in the meantime/

It is absolutely neccessary that you get the newest "quasi-stable" code from "testing"-branch. Because of you have changed code in the meantime you CANNOT PULL (otherwise your changes are lost). First is that you commit your actual changes and push them to your mchf_git_0_0_219_26. The next steps before you change anything in code must be: -change locally to branch "testing" -pull "testing" to your local hard drive

• switch back to mchf_git_0_0_219_26 (thats now your actual code with your last changes)
• merge "testing" to your local mchf_git_0_0_219_26

GitHub has a test function on its website if merging runs automatically or if you must interact in some files. During the whole mchf-GitHub-rpcess all interactives I must do are related to files like "Readme" or "history" - not one code file. Everything worked nearly automatically.

The "devel" branch is my "playground" and you should not take it as base for pulling. Normally that should be "master" but due to many changes by you and by me it is too old to give a good base. So take "testing" - thats the best base.

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-155321873.

[df8oe]

Hello Clint,

the devel is definitely the 219.26.4 included FM - I am working with this version. But I think you did not compile you used the binary... And the binary should be removed. It is too much work to put a binary after a small change.

I agree we must write down for everybody what is useable and how...

"master" and "testing" are branches where the binaries which where built with hthis code are inculded. And these are the ONLY branches where binaries are included and therefore are free for use for "non-coding-users".. All other branches are develop branches and heavily "special".

The "devel"-branch which is on GitHub includes all your changes from your newest push and some beginnings of EEPROM includes. If you want to test it you must built a binary by yourself.

In this moment we are the only active developers. So it is a good idea that we merge our imrovements together to a "common base" and if we think the version is "ready" it ccan become the next "master". In this moment this is the testing branch. I do not wnat to merge my EEPROM code to ist because it is absolutely "not ready". So it remains in my locally devel and/or the GitHub "devel". I am working in this moment on sequential writing because this is minimum 10 times faster than random writing. Same on reading, but that is not so important because of the actual "writeeeprom"-function is so "mudded" that it slows down writing tremendous. When sequential writing is ready I will push it to testing - not earlier.

You develop in another way I have noticed: you do not need such an "instable branch" - you can push to your 219_26_4. When you take "testing" branch as base you have my stable improvements and your stable until 219.26.4.

Of course you can have a look at my devel (it's open source) but it will "change without notice" dayly.

And we must write an "instruction manual" for our Github brnches naming and what is behind it all.

vy 73 Andreas

[ghost]

I did not compile the code, but in both of the sets of files that I downloaded last night I looked at "mchf_board.h" and it showed 0.0.219.24.

Go figure.

Clint

On 11/10/2015 12:57 PM, DF8OE wrote:

Hello Clint,

the devel /is definitely/ the 219.26.4 included FM - I am working with this version. But I think you did not compile you used the binary... And the binary should be removed. It is too much work to put a binary after a small change.

I agree we must write down for everybody what is useable and how...

"master" and "testing" are branches where the binaries which where built with hthis code are inculded. And these are the ONLY branches where binaries are included and therefore are free for use for "non-coding-users".. All other branches are develop branches and heavily "special".

The "devel"-branch which is on GitHub includes /all/ your changes from your newest push and some beginnings of EEPROM includes. If you want to test it you must built a binary by yourself.

In this moment we are the only active developers. So it is a good idea that we merge our imrovements together to a "common base" and if we think the version is "ready" it ccan become the next "master". In this moment this is the testing branch. I do not wnat to merge my EEPROM code to ist because it is absolutely "not ready". So it remains in my locally devel and/or the GitHub "devel". I am working in this moment on sequential writing because this is minimum 10 times faster than random writing. Same on reading, but that is not so important because of the actual "writeeeprom"-function is so "mudded" that it slows down writing tremendous. When sequential writing is ready I will push it to testing - not earlier.

You develop in another way I have noticed: you do not need such an "instable branch" - you can push to your 219_26_4. When you take "testing" branch as base you have my stable improvements and your stable until 219.26.4.

Of course you can have a look at my devel (it's open source) but it will "change without notice" dayly.

And we must write an "instruction manual" for our Github brnches naming and what is behind it all.

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-155548572.

[df8oe]

Definitly not. You must do something wrong. It shows 219.26.4.

You cannot download zip-file. That is always the master branch (219.24). You must checkout locally to the wanted branch via "git checkout devel" (e.g.) and the "git pull". But pay attention if you don't have committed your changes before you do a pull otherwise they are lost. It is a must to commit them to your local working branch as I described some posts before this. No need to push the changes to GutHub now - they ca rest on your local computer. When you have committed you can checkout to other branch and pull the code again.

Other possibility is to look at the file online via browser - but this does not help you to work with the code.

vy 73 Andreas

[ghost]

Well, that's a real "gotcha" if neither "replicate on desktop" or "download zip" actually download the selected branch: I must say that that is indicative of very poor design or documentation - misleading, to say the least.

At the moment I have no changes to commit: I was simply trying to get the "devel" but no matter what I did I seemed to get only the master branch and it seems to have overwritten what I had already in place (e.g. 0.219.26.4) but because I do not trust the Git any farther than I can throw it, I have the entirety backed up elsewhere: The Git has to be one of the most "user-unfriendly" and non-intuitive interfaces that I have ever run across, but no doubt it falls under the category of "It's easy - if you already know how!"

I will look again (sigh) at the several videos/links that you have sent to me and try figure out what in the hell I'm doing wrong.

Clint

On 11/10/2015 1:20 PM, DF8OE wrote:

Definitly not. You must do something wrong. It shows 219.26.4.

You cannot download zip-file. That is always the master branch (219.24). You must checkout locally to the wanted branch via "git checkout devel" (e.g.) and the "git pull". But pay attention if you don't have committed your changes before you do a pull otherwise they are lost. It is a must to commit them to your local working branch as I described some posts before this. No need to push the changes to GutHub now - they ca rest on your local computer. When you have committed you can checkout to other branch and pull the code again.

Other possibility is to look at the file online via browser - but this does not help you to work with the code.

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-155554016.

[df8oe]

Git is absolutely reliable and it works perfect. Every functionality which is needed is present and reachable via a simple command.

And thats the problem...

Git like Linux do search the way for the best soultion for a problem. And the best solution often is to use your fingers to type a few commands in a terminal - not to klick a button or use a GUI.

When I travel to a foreign country the best way to communicate with the people is the LANGUAGE. And if I try to communicate more than "yes, no, black, white, left, right" I will do everything to learn the language which is spoken there. OK - I can draw nice images and try to communicate via pictures (like "Windows") - but I never would reach an acceptable communication with this doing.

So you must throw away your preferences and expectations which come from the GUI-world and think "how can the community development work technically?" We are talking about exact this - and there is a command line tool where no way leads around.

You have to work with the CLI "git".

And you only need these few commands:

git status git branch git checkout git commit git pull git push git merge git add

That are the most recent and there are many websites where you can find very good howtos.

But if you are looking for a "click-and-go-feeling" - you will find NO or if you think you have it is not working as inspected.

"Backup of code"? I do not need this and indeed I do not have locally backups of my projects. All is stored at Github, and it is available even if my hdd is broken. And I never must dig deeply in chenged code because every difference can be inspeced via git commands.

Because of most people who are not involved in programming are "loving their compuer mouse and click-and-go-feling they almost get the stable (master) version when they click on the button "download zip". They do not know what is a branch or a devel version so it is a misktake to offer them functionality of downloading such things. Only developers who know what they are doing can reach full possibilities. Every developer must know many different commands. In C you must know what a declaration is, you create functions with parameters, you use library functions. And the "pool" is hunderd times bigger than he few commands you must know and accept that you need for working with GitHub. So I cannot understand why this is a problem for a developer...

When I try to develop in a new computer language (some months ago I started "Python" I have a good base knowledge so that I must not start "from the scratch". But Python is not "C" or "Java" or "PHP or "ASSEMBLER". It has elements out of these - but many own working parts. If I want to code in this language the best way is to accept it as-it-is and learn the things I don not know. A bad solution will be to look for a tool which translates a given project code from a language I already use to Python so that I do not have to learn it...

But so not worry - all work of the past is not lost. Downloading anything via "download zip" is not working with git - it is "getting something and no need to care about more".

Again ( I did it more than three times) some steps you MUST go:

• Create a new folder on your local hard rive
• pull project to it (without checking out to other branches you always get the master branch)
• if you want other branches, too: DO NOT CHANGE DIRECTORY, CREATE NEW FOLDER E.G.
• just git checkout
• git pull again --> and you have in the same place (!!!!!) code of this branch you can checkout to every branch that exists and pull the branch (I do not say the code - git works smarter than only filling your hard drive with most identical files). So you can hold all existing branches on your local folder. Changing between the branches can be done via "git checkout

If you have cahnged some code in the branch you are working yu are "fixed" to this branch until you save the changes. This is done via "git add" and then "git commit -m"your explanation for this changes". After doing so the changes are stored LOCALLY on you hd. Now you can switch to another branch if you want via git checkout. If you want to upload the changes to GitHub you must push them there:

• git push origin

I do not have the time to exactly repeat the commands I wrote in older posts.

Please change your expectation "how it has to work". No chance - it will not change its behaviour to the expectation of anyone. It works very good and it is easy to work with. The more you reject learning how it works and building a mountain of conditions in your head the longer it lasts if you can work with it.

• It is a powerfull CLI
• you have to use this
• you strictly have NOT TO USE the things a "standard Windows user does" (downloading zips, saving folders, fittting code snipplets from others to your project)

It is much work to manually fit your new version to the existing. I must do this manually and that takes much time. Time we all need for creating things and not to snip out some lines we must search for. If you manually have "saved or deleted things" in your local git folder you have destroyed the existing structure.

If you only have changed one or two files here an easy way how to switch back to actual stage:

• git pull
• git chekcout <name of your 219_26 branch> now copy the changed files to this
• git add
• git commit -m "here I chenged filter setting"
• git push origin <name of your 219_26 branch>

ready....

If you can do so it takes only seconds to fi your changes to the rest. Without it takes hours.

And what you backed up is just the code - not the tree the function "git" builds in a hidden folder and files in there. The backup of the source is not important - if you work with git the important things are located in the hidden folder which git manages. If you only use "git CLI" and do not move, delete or change directory positions on your hdd everything will work fine.

vy 73 Andreas

[df8oe]

Hello Clint,

just after writing my comment I saw that you pushed your new changes to my devel branch.

Because of this branch is my actual working branch and may stay in "non functional state" I recommend not to push anything angainst it.

In this case we have had luck: it is functional (in spite of EEPROM functions). Because of it is not easy to commit your change to the "behind" testing branch (or mcHF_0_219_26_4 branch) tis changes will first appear if I push my devel to testing.

It will be a great idea in future to push only to your branch mcHF_0_219_26_4 or to testing.

vy 73 Andreas

[dl1mx]

Hey guys,

There is a famous tutorial at https://www.atlassian.com/git/tutorials/ which I can highly recommend.

Best regards, Marco

Am 11. November 2015 08:51:27 MEZ, schrieb DF8OE notifications@github.com:

Git is absolutely reliable and it works perfect. Every functionality which is needed is present and reachable via a simple command.

And thats the problem...

Git like Linux do search the way for the best soultion for a problem. And the best solution often is to use your fingers to type a few commands in a terminal - not to klick a button or use a GUI.

When I travel to a foreign country the best way to communicate with the people is the LANGUAGE. And if I try to communicate more than "yes, no, black, white, left, right" I will do everything to learn the language which is spoken there. OK - I can draw nice images and try to communicate via pictures (like "Windows") - but I never would reach an acceptable communication with this doing.

So you must throw away your preferences and expectations which come from the GUI-world and think "how can the community development work technically?" We are talking about exact this - and there is a command line tool where no way leads around.

You have to work with the CLI "git".

And you only need these few commands:

git status git branch git checkout git commit git pull git push git merge git add

That are the most recent and there are many websites where you can find very good howtos.

But if you are looking for a "click-and-go-feeling" - you will find NO or if you think you have it is not working as inspected.

"Backup of code"? I do not need this and indeed I do not have locally backups of my projects. All is stored at Github, and it is available even if my hdd is broken. And I never must dig deeply in chenged code because every difference can be inspeced via git commands.

Because of most people who are not involved in programming are "loving their compuer mouse and click-and-go-feling they almost get the stable (master) version when they click on the button "download zip". They do not know what is a branch or a devel version so it is a misktake to offer them functionality of downloading such things. Only developers who know what they are doing can reach full possibilities. Every developer must know many different commands. In C you must know what a declaration is, you create functions with parameters, you use library functions. And the "pool" is hunderd times bigger than he few commands you must know and accept that you need for working with GitHub. So I cannot understand why this is a problem for a developer...

When I try to develop in a new computer language (some months ago I started "Python" I have a good base knowledge so that I must not start "from the scratch". But Python is not "C" or "Java" or "PHP or "ASSEMBLER". It has elements out of these - but many own working parts. If I want to code in this language the best way is to accept it as-it-is and learn the things I don not know. A bad solution will be to look for a tool which translates a given project code from a language I already use to Python so that I do not have to learn it...

But so not worry - all work of the past is not lost. Downloading anything via "download zip" is not working with git - it is "getting something and no need to care about more".

Again ( I did it more than three times) some steps you MUST go:

• Create a new folder on your local hard rive
• pull project to it (without checking out to other branches you always get the master branch)
• if you want other branches, too: DO NOT CHANGE DIRECTORY, CREATE NEW FOLDER E.G.
• just git checkout
• git pull again --> and you have in the same place (!!!!!) code of this branch you can checkout to every branch that exists and pull the branch (I do not say the code - git works smarter than only filling your hard drive with most identical files). So you can hold all existing branches on your local folder. Changing between the branches can be done via "git checkout

If you have cahnged some code in the branch you are working yu are "fixed" to this branch until you save the changes. This is done via "git add" and then "git commit -m"your explanation for this changes". After doing so the changes are stored LOCALLY on you hd. Now you can switch to another branch if you want via git checkout. If you want to upload the changes to GitHub you must push them there:

• git push origin

I do not have the time to exactly repeat the commands I wrote in older posts.

Please change your expectation "how it has to work". No chance - it will not change its behaviour to the expectation of anyone. It works very good and it is easy to work with. The more you reject learning how it works and building a mountain of conditions in your head the longer it lasts if you can work with it.

• It is a powerfull CLI
• you have to use this
• you strictly have NOT TO USE the things a "standard Windows user does" (downloading zips, saving folders, fittting code snipplets from others to your project)

It is much work to manually fit your new version to the existing. I must do this manually and that takes much time. Time we all need for creating things and not to snip out some lines we must search for. If you manually have "saved or deleted things" in your local git folder you have destroyed the existing structure.

If you only have changed one or two files here an easy way how to switch back to actual stage:

• git pull
• git chekcout <name of your 219_26 branch> now copy the changed files to this
• git add
• git commit -m "here I chenged filter setting"
• git push origin <name of your 219_26 branch>

ready....

If you can do so it takes only seconds to fi your changes to the rest. Without it takes hours.

And what you backed up is just the code - not the tree the function "git" builds in a hidden folder and files in there. The backup of the source is not important - if you work with git the important things are located in the hidden folder which git manages. If you only use "git CLI" and do not move, delete or change directory positions on your hdd everything will work fine.

vy 73 Andreas

---

Reply to this email directly or view it on GitHub: https://github.com/df8oe/mchf-github/issues/10#issuecomment-155696232

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[ghost]

It is clear from you - and from other (locals) that have used the Git that the non-CLI interface for the Git is incredibly bad and poorly designed: No-one with which I have spoken has "easily" been able to adapt to Git without having really screwed things up at first since it can sometimes be difficult to know what happened: Plenty of "playing" with a non-critical, test code base to observe cause/effects seems to be the common advice. Saying that the CLI works perfectly is no excuse for having a piss-poor alternate UI, but since it is clearly the case with the Git - a fact which relatively few people using pushing its use actually seem willing to admit - I'll have to spend more effort in learning the CLI.

I have looked at some of the videos describing the non-CLI UI and most of them appeared to be produced by those who were very familiar with the CLI but, more importantly, had absolutely no business trying to make a video tutorial about how to use that "alternate" (non-CLI) interface, the result being almost laughable and nearly inscrutable to anyone except to those who already knew the material.

Clint

On 11/11/2015 12:51 AM, DF8OE wrote:

Git is absolutely reliable and it works /perfect/. Every functionality which is needed is present and reachable via a simple command.

And thats the problem...

Git like Linux do search the way for the best soultion for a problem. And the best solution often is to use your fingers to type a few commands in a terminal - not to klick a button or use a GUI.

When I travel to a foreign country the best way to communicate with the people is the LANGUAGE. And if I try to communicate more than "yes, no, black, white, left, right" I will do everything to learn the language which is spoken there. OK - I can draw nice images and try to communicate via pictures (like "Windows") - but I never would reach an acceptable communication with this doing.

So you /must/ throw away your preferences and expectations which come from the GUI-world and think "how can the community development work technically?" We are talking about exact this - and there is a command line tool where no way leads around.

You /have to work/ with the CLI "git".

And you only need these few commands:

git status git branch git checkout git commit git pull git push git merge git add

That are the most recent and there are many websites where you can find very good howtos.

But if you are looking for a "click-and-go-feeling" - you will find NO or if you think you have it is not working as inspected.

"Backup of code"? I do not need this and indeed I do not have locally backups of my projects. All is stored at Github, and it is available even if my hdd is broken. And I never must dig deeply in chenged code because every difference can be inspeced via git commands.

Because of most people who are not involved in programming are "loving their compuer mouse and click-and-go-feling they almost get the stable (master) version when they click on the button "download zip". They do not know what is a branch or a devel version so it is a misktake to offer them functionality of downloading such things. Only developers who know what they are doing can reach full possibilities. Every developer must know many different commands. In C you must know what a declaration is, you create functions with parameters, you use library functions. And the "pool" is hunderd times bigger than he few commands you must know and /accept/ that you need for working with GitHub. So I cannot understand why this is a problem for a developer...

When I try to develop in a new computer language (some months ago I started "Python" I have a good base knowledge so that I must not start "from the scratch". But Python is not "C" or "Java" or "PHP or "ASSEMBLER". It has elements out of these - but many own working parts. If I want to code in this language the best way is to accept it as-it-is and learn the things I don not know. A bad solution will be to look for a tool which translates a given project code from a language I already use to Python so that I do not have to learn it...

But so not worry - all work of the past is not lost. Downloading anything via "download zip" is not working with git - it is "getting something and no need to care about more".

Again ( I did it more than three times) some steps you /MUST/ go:

• Create a new folder on your local hard rive
• pull project to it (without checking out to other branches you always get the master branch)
• if you want other branches, too: DO NOT CHANGE DIRECTORY, CREATE NEW FOLDER E.G.
• just git checkout
• git pull again --> and you have in the same place (!!!!!) code of this branch you can checkout to every branch that exists and pull the branch (I do not say the code - git works smarter than only filling your hard drive with most identical files). So you can hold all existing branches on your local folder. Changing between the branches can be done via "git checkout

If you have cahnged some code in the branch you are working yu are "fixed" to this branch until you save the changes. This is done via "git add" and then "git commit -m"your explanation for this changes". After doing so the changes are stored LOCALLY on you hd. Now you can switch to another branch if you want via git checkout. If you want to upload the changes to GitHub you must push them there:

• git push origin

I do not have the time to exactly repeat the commands I wrote in older posts.

Please change your expectation "how it has to work". No chance - it will not change its behaviour to the expectation of anyone. It works very good and it is easy to work with. The more you reject learning how it works and building a mountain of conditions in your head the longer it lasts if you can work with it.

• It is a powerfull CLI
• you have to use this
• you strictly have NOT TO USE the things a "standard Windows user does" (downloading zips, saving folders, fittting code snipplets from others to your project)

It is much work to manually fit your new version to the existing. I must do this manually and that takes much time. Time we all need for creating things and not to snip out some lines we must search for. If you manually have "saved or deleted things" in your local git folder you have destroyed the existing structure.

If you only have changed one or two files here an easy way how to switch back to actual stage:

• git pull
• git chekcout now copy the changed files to this
• git add
• git commit -m "here I chenged filter setting"
• git push origin

ready....

If you can do so it takes only seconds to fi your changes to the rest. Without it takes hours.

And what you backed up is just the code - not the tree the function "git" builds in a hidden folder and files in there. The backup of the source is not important - if you work with git the important things are located in the hidden folder which git manages. If you only use "git CLI" and do not move, delete or change directory positions on your hdd everything will work fine.

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-155696232.

[ghost]

I believe that there needs to be some better documentation in a "findable" location to declare the incremental changes and intents of the code branches: Aside from very brief notes on the branches themselves and having to peruse the code itself there appears to be no way to "know" what has been done or what is intended for the particular branch. I'm not entirely innocent of this, but aside from maintaining the "history.txt" file (and a few others) I've been unsure what to suggest up to this point.

In a previous email I'd taken from one of your previous comments that you'd rather that I'd used the branch with which you'd merged '26.4 and added your EEPROM code, but I clearly read too much into this statement as I pushed '26.5 to is.

As you may have noted, I have been trying to thoroughly document the changes to the code in two places:

• In the "history.txt" file. I have been continuing the documenting of changes that you began with, I believe, the versions following '219.22.
  I seem to be the only one updating this in any recent branches.
• When they are posted, the very large "release notes" file which is a much more thorough explanation of each and every user-facing change to the code, plus a mention of internal changes that are deemed noteworthy, particularly if those might have an effect on usability - this having been useful in tracking some (fortunately!) minor issues that have surfaced in the past to their original appearance to make it much easier to find/fix.

With the additional use of the git there clearly needs to be better communication as to what is/is not to be the development branch intended for incremental releases: My being "new" to the Git and not really knowing what I'm doing isn't helpful in this regard, but it also appears that there are no built-in tools to manage this, either so confusion related to incremental development (e.g. fixes of bugs and addition of minor features) such as which branch to use (e.g. knowing not to push development to the "devel" branch, for example!) is left as an exercise to the users.

Later today I will push the changes to the previous one that had contained '26.4 as you suggest (it will be '26.6 to avoid confusion!) but we really do need to come up with some central document (or equivalent) that contains notes as to what is being currently worked-on and the state of and purpose for branches: It's a Git, so it should be possible, I think...

73,

Clint KA7OEI

On 11/11/2015 1:44 AM, DF8OE wrote:

Hello Clint,

just after writing my comment I saw that you pushed your new changes to my devel branch.

Because of this branch is my actual working branch and may stay in "non functional state" I recommend not to push anything angainst it.

In this case we have had luck: it is functional (in spite of EEPROM functions). Because of it is not easy to commit your change to the "behind" testing branch (or mcHF_0_219_26_4 branch) tis changes will first appear if I push my devel to testing.

It will be a great idea in future to push only to your branch mcHF_0_219_26_4 or to testing.

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-155706317.

[df8oe]

Hello Clint, I agree 100% and now I understand your anger about Git :) But the reason is not Git it is because of you are using bad tools (GUI-tools). Maybe meanwhile there is some which is "ok" - but I don't know it and I never have had heard about the existence of it.

So I think it is the easiest way to do it on CLI. And it is no problem to create a "playing branch" and testing around it. Mostly I have learned by playing around with things and this is my way for learning (but not the way for everyone).

I am sure if you get familar with the "basivs" of CLI you see what a great tool Git is. It consists of two parts: 1) the GitHub (serverside based) software 2) The "git" (locally installed) software.

Only when both fit perfect together it is running smooth.

I have disabled some absoultely unready code in my devel, and pushed the devel branch where you merged your "219.26.5" to GitHub "testing". In testing binaries are included.

All other branches are strongly experimental, maybe malfunctioningg and not for end-users - so I decided not to include binaries to show this clearly.

I the next time when you think 219.26 is "ready for releae" we shall do that. If no more bugfixes are present this should be in the next days. There is enough room in numbers for relasing next "test-version" with added features ;) Master is now really "old". OK - thats the price for starting with GitHub but I am sure the decision is correct and will lead us to much more possibilities. Please have a look at the posts where I wrote some CLI commands. Test them out - first by pulling all branches which are available to your local computer and the swith between the branches to see what ahppens and how it works. If you do have concrete questions don't hesitate and write them down here - I will help whereever I can. But I have no time to write everything down which exists - I am sure I do not know every feature of Git indeed.... A few hours ago I searched (and found) explanations how not to merge different branches together but single commits to a branch - incredible.... But I decided to push the "newest devel" to testing - no unwanted things will happen because I disabled my alpha-code and everything works as before. Users can see a snapshot of upcoming hardware-development - and that is interesting but not dangerous :)

vy 73 Andreas

[df8oe]

I forgot:

Please DELETE (or DO NOT USE) your "old branch". Because of I merged it to devel now let's start with a new branch. Normally not ok but because master is quite old now take actual testing for the base of your next steps. Today it is identical to my development - but may change in short time.

I propose naming as following:

My devel: devel-DF8OE-0.0.xxx.yy.z Your devel: devel-KA7OEI-0.0.xxx.yy.z ...and all branches of other coders similar.

Everyone should only push to HIS branch. Because of I gave you the state as COLLABORATEUR you have the possibility to push to my branches (normally impossible). Actually I will review the changes and merge them to a "testing" version where all "goods" are included. Testing branch includes binaries and is intended for end-users who are interested in playing around with new features. Later when you have learned how to do of course you can review and merge devels to a testing, too. But in this stage this is not a good idea...

vy 73 de Andreas

[df8oe]

About "documentation":

The version.txt is a good place to explain SHORTLY what is done. I will continue this with every release of my changes to testing. Because of you do not merge in this moment you should extend version.txt in your devel each time you pushed something to GitHub. I will fit this to the version.txt in testing.

Bigger documentations I intend to put in folder "useful documentation". Older versions should be removed.

Puuuh.... enough in this moment...

vy 73 Andreas

[ghost]

Do you mean "version.txt" or "history.txt"? It is the latter that I have been updating.

On 11/11/2015 9:23 AM, DF8OE wrote:

About "documentation":

The version.txt is a good place to explain SHORTLY what is done. I will continue this with every release of my changes to testing. Because of you do not merge in this moment you should extend version.txt in your devel each time you pushed something to GitHub. I will fit this to the version.txt in testing.

Bigger documentations I intend to put in folder "useful documentation". Older versions should be removed.

Puuuh.... enough in this moment...

vy 73 Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-155834039.

[ghost]

I must admit to being confused at this point.

From where should the proposed new branch be forked? The current DF8OE "devel" appears to be unstable according to reports that I'm getting, problems relating to the code relating to the external EEPROM - and you did suggest that I continue with the mchf_0_219_26_4 branch in a recent email, below.

For the moment I will push '26.6 to the above branch as the bug that it addressed (the 2.3 kHz filter) was fixed by replacing a "==" with a "!=" and I will "re-fix" the a number of the compiler warnings that I was getting before. Because it is the Git, such changes should be easy to incorporate as deemed appropriate.

Clint

On 11/11/2015 9:16 AM, DF8OE wrote:

Hello Clint,

just after writing my comment I saw that you pushed your new changes to my devel branch.

Because of this branch is my actual working branch and may stay in "non functional state" I recommend not to push anything angainst it.

In this case we have had luck: it is functional (in spite of EEPROM functions). Because of it is not easy to commit your change to the "behind" testing branch (or mcHF_0_219_26_4 branch) tis changes will first appear if I push my devel to testing.

It will be a great idea in future to push only to your branch mcHF_0_219_26_4 or to testing.

vy 73 Andreas

I forgot:

Please DELETE (or DO NOT USE) your "old branch". Because of I merged it to devel now let's start with a new branch. Normally not ok but because master is quite old now take actual testing for the base of your next steps. Today it is identical to my development - but may change in short time.

I propose naming as following:

My devel: devel-DF8OE-0.0.xxx.yy.z Your devel: devel-KA7OEI-0.0.xxx.yy.z ...and all branches of other coders similar.

Everyone should only push to HIS branch. Because of I gave you the state as COLLABORATEUR you have the possibility to push to my branches (normally impossible). Actually I will review the changes and merge them to a "testing" version where all "goods" are included. Testing branch includes binaries and is intended for end-users who are interested in playing around with new features. Later when you have learned how to do of course you can review and merge devels to a testing, too. But in this stage this is not a good idea...

vy 73 de Andreas

— Reply to this email directly or view it on GitHub https://github.com/df8oe/mchf-github/issues/10#issuecomment-155831996.

[df8oe]

Am Mittwoch, 11. November 2015, 16:28:49 schrieb cctbcn:

I must admit to being confused at this point.

From where should the proposed new branch be forked? The current DF8OE "devel" appears to be unstable according to reports that I'm getting, problems relating to the code relating to the external EEPROM - and you did suggest that I continue with the mchf_0_219_26_4 branch in a recent email, below.

The devel is stable - I cannot see where the described problem can be located.

I do a test BEFORE LCD initilization starts and then set the variable which holds "EEPROM internal use - EEPROM external use" to "external". When bootscreen appears, my testing code has successfully been run and no other code is active.

I have added two variables to the end of transceiverstruct ts - you can take a look. That can be the only problem that preparing new fw changes transceiverstruct and do not mention the two new variables.

But I have updated two mchf which habe serial EEPROM attached and it worked fine.

Don't use the older branch - take the testing branch which is identical at the moment with my devel. If there can be a problem in "updating new firmware deected" because transceiverstruct ts is changed, please implement that there are now two new variables added. And tell me if this can be the problem (I don't think so).

And about short documentation: Sorry I was mistaken. Please use "history.txt". "version.txt" only should hold actual version number because it is automatically read by script on mchf-GitHub-Website to show correct available versions without updating html each time.

vy 73 Andreas

[df8oe]

closed.