[BUG] TOT Time Out Timer loop with external PTT reactivation

[Roturbo]

Hello,

Describe the bug
Time Out Timers only work with Mox on screen, with my Anan 100D i´m using the PTT
input on DB25 that also enable the MOX, but since the PTT is a fixed switch TOT only
resets and come back again on air (loop) because the pin is still connected to ground.

To Reproduce

General/Options/Options-2

MOX enable to 30s,, direct PTT to radio on DB25 or other radios back panel
PTT input it goes off and back to on again.

Expected behaviour

The expected behavior is the PTT should be turned off and radio goes to RX and
only back to TX after a external PTT release/reset after x time for example.

This is important because of accidental PTT press for long time that may damage
the radio or put on the air any talk near the microphone.

Regards

[ramdor]

fixed in latest master, will be released as test version at some point

[Roturbo]

Tanks ramdor for your work.

Regards

[Roturbo]

Hello ramdor,

i have test the last release, it is different now, the radio pass to RX but the PTT output to PA keeps active,
i notice because the waterfall starts running, the state of the radio change from TX to RX but there was
no reception because the PA have the relay actuated for TX.

I have mod my radio using a relay activated by the PTT output, than the contacts of the relay is switching to GND
the PTT line (RCA) that goes to PA, i did this to separate the radio from the 12v coming out of the relay coil inside the PA to
avoid any interference on RX.

Today i recheck the manual and schematics.

To confirm that i didn´t make any mistake i did a test with PTT Delay to 1 second, and i did see the 1s
delay timing for PA output after i release the PTT.

I may be wrong, but maybe some instruction is missing to cut out also the PTT out,, because the inside
relay for RX change the state.

If necessary to make any test please tell me.

Regards

[ramdor]

I have just tested this and it works fine on my 7000dle MK2, and also OE3IDE (Ernst). I don't have a radio with the D25 input, so unable to test that, but I am not sure why that would be the issue as the ToT code essentially does the same as pressing the MOX button to false.

Config

• ACOM amp keyed via PTT OUT rca socket on back of radio
• ToT set to 30 seconds
• In Setup->General->H/W Select, PTT set to ON

1. When radio is keyed via the MOX button on the UI - all ok, ToT fires and ACOM moves out of TX
2. When radio is keyed via the TUN button on the UI - all ok, ToT fires and ACOM moves out of TX
3. When radio is keyed via the PTT IN rca socket (shorted and kept shorted) - all ok, ToT fires and ACOM moves out of TX, even with PTT IN continually shorted

During the above tests, OC was also configured, and the OC TX pins turned off as expected

[Roturbo]

Hello again,

The 100D and 200D don´t have the RCA PTT input they only have RCA output, the same
output is present on DB25 pin 1, the PTT input is on DB25 pin 13 the 10E and 100 also have
the header with some different pin out.

Once the PTT OUT is activated from the FPGA that turn the Q2 to GND i think that
the PTT IN is not connected to the same place but it acts like that.

One last test i did and sound strange, MOX activation on display at the end of TOT
give me the 1 second normal PTT delay than RX, but a short PTT activation from DB25 instead
of only 1s delay i get a buz sound on pc speakers during the same delay time,
maybe different paths.

Ramdor, i don´t discard that i may have make a mistake, but i don´t know were to look
to find the problem, maybe we have to wait for others with same radio to test.

[ramdor]

Not sure why this got closed, reopening.

@n1gp Any idea about all of this Rick? All tests here on 7000 work as expected. The issue is related to the ToT (time out timer) implementation. Ignore the first three posts in this thread as that was a different issue.

[n1gp]

@Roturbo

What is the firmware version you are using and have you tried others?

I have a Hermes board here (not Herme-lite), so I can try to replicate using
that. Can you give me some clear steps to reproduce and what I should
look for?

[ramdor]

@n1gp seems that he is saying the following

1. use pin from d25 pin 13 to key up radio, and when this happens, rca ptt out and pin 1 from the d25 acts as expected
2. if pin 13 is held shorted to ground and held there, and the software causes a ToT (time out timer of 30 seconds) to fire, Thetis essentially presses MOX (sets all mox to false), however the rca PTT out and the pin 1 still causes external amp to be keyed, even though thetis has switched into RX
3. also even though radio/software is now in rx, the trx relay does not switch to rx mode

That is my understanding of it anyway. When this exact same thing is done on a 7000, keeping the PPT in shorted after a ToT, then it will go into RX and external amp will unkey as expected

[n1gp]

Tnx @ramdor, I have been able to replicate this behaviour on my
HPSDR Hermes board. PTT OUT will stay engaged after the timeout.

I have found some FPGA code differences between Orion_MkII and
Hermes based boards.

I'll put some changes to test and get back...

[Roturbo]

@n1gp

Hi,

and i didn´t try other firmware's yet, but i think this will affect also the 200D and similar old boards.

Regards
.

[ramdor]

@n1gp i figured it must have been happening in the f/w, and i guess is being held and not released if that pin13 is kept in the appropriate state. Cheers for looking into it Rick.

[n1gp]

@Roturbo

I made 3 images below that have a potential fix for the ToT issue.
If you find that one doesn't work, or that it gets SEQ errors, try another one.

Let me know if you find one that works and if it solves your ToT issue.

https://www.dropbox.com/scl/fi/ggy095maldu3b8r7jt3it/Metis_Angelia_Protocol_2_v12.2.5A.rbf?rlkey=mtldx6b73c6hdx7aodoj4q5eq&st=c8pcujty&dl=0

https://www.dropbox.com/scl/fi/apkkabrtgbavpmc2crts7/Metis_Angelia_Protocol_2_v12.2.5B.rbf?rlkey=1rf268n6oe3uooe64c3csau59&st=86c00fjp&dl=0

https://www.dropbox.com/scl/fi/kqxmiss8le7czy2n119k3/Metis_Angelia_Protocol_2_v12.2.5C.rbf?rlkey=d71omslo1wwd1b1u8ns5ghz6y&st=q2y4o81r&dl=0

[Roturbo]

@n1gp

Hello, here is the report.

A.. No boot.

B.. Boot but with SEQ errors just by changing freq, didn´t test the TOT.

C.. Boot, working and no SEQ errors on the short tests that i have made,
and more important, TOT is working normal now, PTT-out does turn off
at end of TOT and only turn on again after a PTT-in release and pressed again.

I notice one thing, i have a PA profile 10w only, and normally with v12.1.18
i get unstable power, oscillating from 8,9 and sometimes 10w, with this version
12.2.5C i get 13W on first test, and i never get over 10W before.

Is there any chance that Firmware have anything to do with it ?

I already try to find the Bias current value and the correct way to tune it
but is not on manuals, any help is welcome.

Regards

[n1gp]

Hi @Roturbo

Tnx for the report. Seems like a step in the right direction.

It also shows how the 'free' version of Quartus makes different decisions
between compiles. There were absolutely no code or constraints changes
between those builds. Only the SEED value was changed:
https://www.intel.com/content/www/us/en/docs/programmable/683145/21-3/change-fitter-placement-seeds.html

I did a compare of v12.1.18 and this v12.2.5 and I see that the only change for
transmitter side code was using a 122.88MHz clock that was derived from the base
clock rather than using the base clock. It may be that or just the different decisions
that quartus made during the compile.

How does the power out look at other than a 10 watt setting? I can generate some more
images for you to try if you think that 'C' is not usable for you.

[Roturbo]

Hi @n1gp

Interesting how a compiler do that things, i don´t know much about coding,
but is the kind of situations that may kill a project if a programmer don´t know that details.

Yes please generate some images and i will try, my programming skills are basic things with
Arduino, and i use part of code that i see on the web.

Now i´m testing it again, still no SEQ errors, more stable the power, but i think that there is also
some hardware problem, maybe cold solder joint as i already found one before.

The unstable power makes the PS put out some spikes and most of the time is not pure,
and i already have the mod input for PS on the 100D.

I don´t know if there is any relation, but sometimes i start to lose power on the 10w setup, 4w 6w or less,
i change to default Anan100D press 2 times on TUN the power it the 97w 98w, than i go back
to 10W settings and i get again more power output close to 9w, this new firmware is hitting the10w
and 11 and 12w most of the times, all tests done on dummy load.

Regards

[Roturbo]

@n1gp

Today testing the PS with PA i notice that there is no PS after all.

Go back to 12.1.8 and the PS is back again.

After all Rick, we have to try to fix PS first, any new files post here and i will test it, and this
time i will check the PS and will report it also.

PS- i forget to check if PLL was locked.

Regards
.

[n1gp]

@Roturbo

Here are 3 more images to test. Some more things to look for besides PS:

Things to test using Thetis:

• There is RF output with QSK CW selected
• Pure Signal is working
• ADC0 and ADC1 both work (route ADC1 from RX2 on back)
• All Bands are working
• Diversity is working
• Wideband is working
• Sequence errors do not happen on transmit nor receive
• No jumping of noise floor where it sticks in high position
• Attenuators are working
• OC Controls are working
• Ant 1-3 connectors are working

https://www.dropbox.com/scl/fi/g65xy6zb7d23nod7day7e/Metis_Angelia_Protocol_2_v12.2.5D.rbf?rlkey=x10t4o3wsgme1m2zuxnc9xvkl&st=ctfeas0w&dl=0

https://www.dropbox.com/scl/fi/88yew7x7207a0580if8zq/Metis_Angelia_Protocol_2_v12.2.5E.rbf?rlkey=gysr29f6fqu8k4cqjs8q1oloy&st=zaxz6pck&dl=0

https://www.dropbox.com/scl/fi/sdtok8ke5rte9dpsm22qi/Metis_Angelia_Protocol_2_v12.2.5F.rbf?rlkey=6pros2w0bt7uwjrrd0nfp7jj7&st=qi5pcmsr&dl=0

[Roturbo]

@n1gp hello

--There is RF output with QSK CW selected--

i don´t do CW, but i will improvise a key with a 3.5mm jack

--ADC0 and ADC1 both work (route ADC1 from RX2 on back) --

What do you mean with "route ACD1 to RX2 on back" ?
please give me more details about this test

--OC Controls are working--

Not using OC at the moment, do i need to check all 7 on TX and RX or only 1 is ok ?

Please inform.

[n1gp]

Hi @Roturbo

I wouldn't bother checking any of the rest of the tests if the image is causing SEQ errors
or some other still working, but not quite right, problem. But once you find one that works
for what you use most then try some of these other tests.

--ADC0 and ADC1 both work (route ADC1 from RX2 on back) --
There should be an RX2 BNC input on the back and that is routed to ADC1
In Thetis you can go to setup->ADC and select either ADC0 or ADC1 per DDC
The idea is to make sure ADC1 is working OK.

--OC Controls are working--
Probably just test on one, RX or TX.

[Roturbo]

@n1gp Hi

Fist easy tests are done.

V12.2.5D

---There is RF output with QSK CW selected
ok-- Pure Signal is working
---ADC0 and ADC1 both work (route ADC1 from RX2 on back)
ok--- All Bands are working
ok-- Diversity is working
ok--- Wideband is working
ok--- Sequence errors do not happen on transmit nor receive
ok--- No jumping of noise floor where it sticks in high position
ok--- Attenuators are working
---OC Controls are working
ok-- Ant 1-3 connectors are working

V12.2.5E
not OK---Pure Signal is working

V12.2.5F
not ok, also audio distortion ---- Pure Signal is working

---

Rick, sorry for my lack of knowledge, but i didn´t understand were to route the BNC on RX2.

Please clarify with more details how to make this test,, later with more time i will do the
missing ones from the list to see if the version D is all ok.

Regards.

[n1gp]

@Roturbo

Seems like V12.2.5D is looking pretty good so far.

For testing ADC1, put your antenna on the RX2 BNC input.
Then go to Setup->ADC and set both DDC2 & DDC3 like this:

and then make sure you are getting RF in the spectrum.

[Roturbo]

@n1gp

Hi Rick, sorry i didn´t understand the RX2 test at first.

OK,, detects and change to CW---There is RF output with QSK CW selected

OK ---ADC0 and ADC1 both work (route ADC1 from RX2 on back)

ok--- Sequence errors do not happen on transmit nor receive

OK ---OC Controls are working

OC are working but EXT PA Control (xPA) is not working, first i chose a pin for TX, next press
the xPA button for activation, TX or RX there is no change in chosen OC pin using external PTT ,
MOX, 2TUNE or TUN.

I checked the OC pin to confirm it goes to GND on my test not only the green or red indicator, i have uncheck
BCD band pins to try xPA and did the same on reverse to confirm there was no interference.

On the xPA case, tell me how to proceed if you need more test, one more thing i notice is,
the Transmit PIN Action is also affecting the Bands BCD selection, this action is not supposed
to interact only with xPA, i´m wrong and not seeing the logic or it makes sense because
there is always a option for other functions in case someone need ?

@ramdor
One more thing i found now, the J16 TX/RX are not working on 11m that normally is the
same filter for 10 and 12m,, can this be adjusted in software ?

Rick i have a friend with a 200D, he is using this version and he always complain
about SEQ errors but only on RX,, the TX seams to work normal without problems.

He is not able to do some test like external PTT on DB25 but if you have any
new firmware for this model please send here and i will help him to update,
need also that version in case something goes wrong i can go back.

Regards

[n1gp]

@Roturbo

Tnx for your testing and I'm glad that we have a firmware image that ticks most of the boxes.

@ramdor ?
I think if the OC 7 outputs are working that maybe the firmware is OK.
Maybe the xPA use of them is at fault? I'm not sure, but will try to do
some tests there myself.

Meanwhile, for your 200D friend, have him try these images. I have had good
reports on the Metis_Orion_NP_v1.9.20B.rbf image:

https://www.dropbox.com/scl/fi/533lisrd8m1p1nmc697dp/Metis_Orion_NP_v1.9.20B.rbf?rlkey=vyjs05mfjxmec3lrrh9eq4anm&st=los50psr&dl=0

https://www.dropbox.com/scl/fi/rzl2a0c88rsh6bq0uo6gk/Metis_Orion_NP_v1.9.20C.rbf?rlkey=dgivriqntwm0p54b02u366clt&st=4ilddsyw&dl=0

https://www.dropbox.com/scl/fi/4wee06ok6oksq4czzopbm/Metis_Orion_NP_v1.9.20D.rbf?rlkey=dsnfl55t696b8hz7q0quh554p&st=4l7y9pg3&dl=0

[Roturbo]

@n1gp

I have mention ramdor because i think it is something with the software, before
there was similar case were change antennas was not available on 11m and
other bands, in this case change filters on BCD is doing the same,, only
works if ham bands are selected.

The xPA issue can also be related to software, but is better to wait for your
tests, tanks for the 200D files once he have the time we will try and report.

Rick, i was reading about the firmware´s and found this, that i also check at my side.

https://community.apache-labs.com/viewtopic.php?f=32&t=4972&start=30#p28511

HOWEVER, I noted a TX problem on 15, 12, 10, 6m where the TX signal (monitored on DUP)
had many small spurs over a wide spectrum (~350kHz).

Some bands are very clean on my radio other like on that post have many small spurs,
on some cases it goes to the limits of the max zoom out with sample rate of 768000.

6m

10m

12m

15m

17m

20m

40m

80m

The other bands were all ok so i didn´t post the picture, maybe you want to add this spurs test
to that list for future evolution on firmware.

All test done with dummy load and 2tone, but with TUN it is also present see next pic.

Is possible that this small spurs are also related to some audio reverb on TX ?

Waiting for your replay.

[n1gp]

@Roturbo @ramdor

I tried out testing the xPA issue. I am not seeing the OC pin that I selected
go to GND during TX or RX. The xPA on the console is enabled.
I have never used these before so I'm not sure if I'm missing something or
that there is an issue with the SW. @ramdor could you give that a test or
clarification when you get a chance?

As for the spurs, how do these compare with your v12.1.8 firmware? Just to
get a baseline. I have seen issues relating to the 122.88MHz clock used for
the DAC before. Also just due to the quartus build differences.

I'm curious as to how this relates to your v12.1.8 firmware and then we can
try some different builds with another 122.88MHz clock on the DAC.

[Roturbo]

@n1gp Rick, i was thinking the same as i don´t remember doing this test before,
and i don´t know how it goes,, check it now.

6m

10m

12m

15m

17m

20m

40m

80m

I have perform the test with 12.1.18 with same conditions as the 12.2.5D, the next pic is also with
12.1.18 in 80m but i manage to give a little more feedback to see more signal.

80m

And i did the same with more feedback again on 10m

10m

Please judge by yourself, i don´t see the same type of spurs, but the 2Tone still makes small
fading spurs and cleaner far from center, that seams more normal than the 12.2.5D throw out.

Regards

[n1gp]

@Roturbo

Thanks for the testing you've been doing here.

Yes, the v12.1.8 definitely looks better. Although I wonder what that blip is
on 40m off to the right (~7180). It's on both versions.

I put the 122.88MHz clock back to the DUC as it was in v12.1.18 and made the
four images below:

https://www.dropbox.com/scl/fi/7cqrbeo5euzgbzj1shduv/Metis_Angelia_Protocol_2_v12.2.5G.rbf?rlkey=g5zf3annn8qvlywn96c7c4b0h&st=6rjv0uit&dl=0

https://www.dropbox.com/scl/fi/ibbuc11s78u4ohrw1zfay/Metis_Angelia_Protocol_2_v12.2.5H.rbf?rlkey=8jzwjjdqk1hpvy0dgpjfvuenp&st=994yu8f3&dl=0

https://www.dropbox.com/scl/fi/p2wfgyi19kdn9xozbnkx4/Metis_Angelia_Protocol_2_v12.2.5I.rbf?rlkey=h5xkxr2s7kys46oab35rlhyrc&st=y6sdpayf&dl=0

https://www.dropbox.com/scl/fi/ew8562pa0hobl2gr6f6n0/Metis_Angelia_Protocol_2_v12.2.5J.rbf?rlkey=rkg7tu44g7pzy3oqngcwt1id0&st=mm4l01x8&dl=0

[Roturbo]

@n1gp

No need to tanks, it is us all that benefit from your firmware work that must tank you.

I also notice that blip on 40m, it is steady independent from the tuned freq,
with TUNE it is there also, i don´t remember exactly how, but on more than
one test yesterday i didn´t see it, just don´t know witch firmware i was
using or what i have done different.

40m 2TONE at 7.150 50w on dummy load

Same on 7.195

Again on 7.195 this time i turn off PS, but the 31dB attenuation was hiding the signal,
so I adjust the attenuation for better view

Move to 7.100 and that spike didn´t change place

After locking for any TX options i try to uncheck the "ByPass/55 Mhz HPF" and it gets better or normal output.
7.100

7.195

If i check the "HPF ByPass on TX" the blip is there again, to avoid this the option
is to uncheck the 2 options at same time.

From what i understand the "ByPass/55 Mhz HPF" was only on RX as i can ear the relay clicking,
also with WideBand open i see that this option is changing the signal bellow 10mhz but if is a High
Pass Filter why is affecting low than 55Mhz ?,, can you please explain me this better as it is
affecting TX and making that blip ?

For reference 40m band selected.

---

10m band selected

Can it be another glitch/bug in firmware/software or is working normal ?

---

Now about the last 4 firmware´s you send.

G-- PS not working
H- SWR warning on dummy load
I- SEQ error on TX and crashing
J. PS not working or something worst disturbing the signal, see bellow pic

This type of image was present using 2Tone on all bands from 6m to 160m,
with TUNE the signal return was the same.

[n1gp]

@Roturbo

I have seen the spurs on TX when firmware isn't meeting timing but I have yet to see
that blip on 40m. I can't think of a reason why unchecking the "HPF ByPass on TX"
AND "ByPass/55 Mhz HPF" would make the blip go away. I have read some reports
of strange things happening on RX when the 6m LNA transistor goes bad.

This issue may be a good one to take up on the Apache-Labs forum. Scott / WU2O
I bet would have some ideas.

I usually compile the firmware on the command line so I can build several versions
at a time. I used the GUI and found that the build wasn't quite making timing after
changing that DUC clock.

I adjusted the constraints to make timing and build these new four images:

https://www.dropbox.com/scl/fi/yovtosqtjr2uv403ced0w/Metis_Angelia_Protocol_2_v12.2.5K.rbf?rlkey=yxbsfcfe169jy6jkflvls8ou4&st=y7r12em5&dl=0

https://www.dropbox.com/scl/fi/ksxf4w8y82o4apdt42h93/Metis_Angelia_Protocol_2_v12.2.5L.rbf?rlkey=9iw7fnmi8pwakafry2mr70vod&st=343aqwe6&dl=0

https://www.dropbox.com/scl/fi/cql6zvqqgiiv0mlw8j2io/Metis_Angelia_Protocol_2_v12.2.5M.rbf?rlkey=wqcqxe0qac0k6xdmsiz310iek&st=ixivxzgu&dl=0

https://www.dropbox.com/scl/fi/qevwzgiknbwswypm7zxls/Metis_Angelia_Protocol_2_v12.2.5N.rbf?rlkey=n05qb0iqbbb1i6x19i709kjaa&st=ayksgwpw&dl=0

[Roturbo]

@n1gp

I have try to register once on the Apache Labs forum but never receive
any confirmation maybe they only accept with ham call sign, if you can
talk with someone i would like to participate there also.

The last 4 firmware´s.

k- PS not working signal disrupted
L- PS not working signal disrupted
M- PS not working signal disrupted
N- some bands were ok,, other don´t have PS, at some point all were bad.

I was doing the test and posting here the pics.

6m

10m

12m

15m

17m

20m

---

At this point i go back and retry the 10m and it all goes bad, 10m and other were all wrong.

10m

---

i reflash the N version again.

10m

Next all seams to work but on 40m and after pressed 2TON some times the signal goes wrong again,
it is the first time i see a firmware that change after some time, also notice that if the signal is at a center
of a long inverted V than something is wrong, you can see this on first picture, wen firmware is ok all
the signal before and after the center signal are flat.

Conclusion, none is working, back to 12.1.8 working and waiting for you.

Regards

[n1gp]

@Roturbo

Hi,

I checked with the Apache Labs Community moderator and they only
accept with valid ham call sign.

I have taken a few new approaches to this problem and want to do a quick
check to see how these decisions affect the situation.

I have seen, rarely, when a firmware upgrade can work sometimes intermittently.
Just make sure when you upgrade the firmware that you use the HPSDRBootloader
and NOT the HPSDRProgrammerV2-nopcap as the HPSDRBootloader is much more
reliable programming byte for byte although it's quite a bit slower.

I have only one image now to try and depending on the results will try more or
re-evaluate the direction:

https://www.dropbox.com/scl/fi/17wew0unq687ev8evs069/Metis_Angelia_Protocol_2_v12.2.5O.rbf?rlkey=f1hatq0lgkedhwwdnttjpv6z4&st=ejphmjsc&dl=0

[Roturbo]

@n1gp Ok Rick, any update let me know.

I always use HPSDRBootloader, sometimes it takes a little more time other is faster,
this last firmware the PS was not working, on some bands it kicks with erratic
signal on AmpView but most of the time no FeedBack or any try to correct,
on TX there were also some ADC errors.

[n1gp]

@Roturbo

I'm running out of ideas and it is difficult that I don't have a 100D
to test with.

These next four images have some changes in the PS area:

https://www.dropbox.com/scl/fi/3f3q9pkcw5y177ltg1tll/Metis_Angelia_Protocol_2_v12.2.5P.RBF?rlkey=ksn7wlzkagexssk7kx4f550j1&st=wjcpuzsz&dl=0

https://www.dropbox.com/scl/fi/3wgdhng9mzpswwfkpssdy/Metis_Angelia_Protocol_2_v12.2.5Q.RBF?rlkey=pvfiez8xijv18bmqah87ur99p&st=xfxcq2pd&dl=0

https://www.dropbox.com/scl/fi/6mspo9ekz726o18fvow3r/Metis_Angelia_Protocol_2_v12.2.5R.RBF?rlkey=d3i0y2u6fym1ahjkbduikr1lu&st=nxdqn27i&dl=0

https://www.dropbox.com/scl/fi/qhco5b1q1w1hye6am7qbv/Metis_Angelia_Protocol_2_v12.2.5S.RBF?rlkey=qdjofz3w6lthkb26a9d292inz&st=hia3najh&dl=0

[oldjackbob]

Just a question @Roturbo, do you have the correct value in the PureSignal SetPk field? If that value isn't correct PS may not function correctly (or at all).

Mark

[Roturbo]

Hi @n1gp, i think it is the correct value check next pic

The amp view also looks normal

After i test the firmware´s you send i go back to 12.1.8 and confirm if the PS is back to normal,
later i will test the last ones and will inform,, i hope we have luck.

[Roturbo]

@n1gp here is the last files report.

P-PS not working,, many small spurs
Q-PS signal stable on AmpView but many spurs and DDC errors
R-PS not working spurs
S-PS not working, spurs and DDC errors

I have to change the last files extension from upper case to low case, the HPSDRBootloader didn´t
want to load the files, also notice the different files sizes, the 12.1.8 is about 1620KB the next files
you send range from 1361 to 1367KB, the last 4 files have are about 1410~1416KB in size.

The different sizes maybe are related to how the compiler process it, or some other thing
that i´m not aware, and probably don´t interfere because i have older P2 versions that
are also on the 1360KB range size, so it is just one observation

I don´t mind to make the test, if you want some other specific test just tell me,
i´m here to help.

[n1gp]

Wow, that is one picky 100D!

The file size changes are due to the number of DDCs in the firmware.
12.1.8 actually has 8 DDCs so it is the largest.

More DDCs = more logic used in the FPGA.

Most of the ones I sent before are 4 DDCs. The last ones I sent have 5 DDCs,
one of them is dedicated to PS. This is the exact same way/code that the Orion2
is using in it's latest firmware.

If I think of something new to try I'll copy you here.

[Roturbo]

hi @n1gp , i have send you one e-mail.. did you receive it ?

[n1gp]

Hi @Roturbo, no I have not received any email from you. Not even in my spam folder.

[Roturbo]

@n1gp it is your call sign at hotmail correct ?

Confirm so i can send it again.

[n1gp]

Yes, that is correct.