|
Things are a little improved. There is a call to tft.fillRect() that
erases the area where the frequency is displayed. Theorizing that
audio interrupts are held back while that's done, I split it up into 5
fillRect()s. So - clear this little bit, then come up for air and let the
audio go. Then clear the next little bit, then come up for air... etc.
I disabled updating VFO-B, and divided the clear of the current frequency
into 10 mini-clears. Much Better! The audio is still chunky, but you can
hear what you're tuning past.
An obvious next step is to *selectively* rewrite stuff. Why erase and rewrite
stuff that hasn't changed? Keep a string variable "displayed frequency". Or to
make it even simpler, have an array of 8 bytes: Character displayed in first position, character displayed in second position - etc. Then erase and rewrite
ONLY those characters that have changed.
- Jerry, KF6VB
toggle quoted message
Show quoted text
On 2025-02-01 20:39, jerry-KF6VB wrote: I suspect I understand...and it's not good.
I think that SPI requires precise timing, and audio interrupts are
disabled during long video transfers.
Yet... the audio works fine while the spectrum, the S-meter bargraph,
and the waterfall update. Sigh.
- Jerry, KF6VB
On 2025-02-01 18:50, jerry-KF6VB wrote:
...When tuning.
The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is
unpleasant. As you tune around, you get tiny
blips of sound, interspersed with long display updates. You basically
cannot hear what you're tuning past.
I just tried commenting out the bit of code that displays the
frequency as you tune. Tuning is much better.
There is still a burst of nasty noise with each encoder *tick*, but
it's short, and you can easily hear what you're
tuning past.
Naturally, that's not a real fix. The instant you start tuning, the
frequency display is wrong...and that's just wrong!
What would be a fix? A few things: First of all, we *could* do a
timer thing where we don't bother to display
the frequency until we stop tuning. There was tuning, and now there
isn't? Ok, display where we got to. Still not optimal.
I note that it always updates ALL the digits of the frequency, even
those that haven't changed. It even
redisplays the VFO B frequency. Surely it doesn't need to update all that.
Also - I wonder why on earth the audio pauses or stops or gets
discarded while it writes the display? Surely
audio interrupts can continue during this time....?
- Jerry, KF6VB
|
Hmmm Stripping functionality out of the radio. Quite the dilemma when you
will likely prefer to "do more" with your radio long-term than less...
Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ
VP2EHZ
Owner - Operator
Big Signal Ranch ¨C K9ZC
Staunton, Illinois
Owner ¨C Operator
Villa Grand Piton ¨C J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com
Moderator: North American QRO Group at Groups.IO.
Moderator: Amateur Radio Builders Group at Groups.IO.
email:? bill@...
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected]< [email protected]> On Behalf Of jerry-KF6VB Sent: Saturday, February 1, 2025 11:06 PM To: [email protected]Subject: Re: [SoftwareControlledHamRadio] Not Displaying the Frequency.... Things are a little improved. There is a call to tft.fillRect() that erases the area where the frequency is displayed. Theorizing that audio interrupts are held back while that's done, I split it up into 5 fillRect()s. So - clear this little bit, then come up for air and let the audio go. Then clear the next little bit, then come up for air... etc. I disabled updating VFO-B, and divided the clear of the current frequency into 10 mini-clears. Much Better! The audio is still chunky, but you can hear what you're tuning past. An obvious next step is to *selectively* rewrite stuff. Why erase and rewrite stuff that hasn't changed? Keep a string variable "displayed frequency". Or to make it even simpler, have an array of 8 bytes: Character displayed in first position, character displayed in second position - etc. Then erase and rewrite ONLY those characters that have changed. - Jerry, KF6VB On 2025-02-01 20:39, jerry-KF6VB wrote: I suspect I understand...and it's not good.
I think that SPI requires precise timing, and audio interrupts are
disabled during long video transfers.
Yet... the audio works fine while the spectrum, the S-meter bargraph,
and the waterfall update. Sigh.
- Jerry, KF6VB
On 2025-02-01 18:50, jerry-KF6VB wrote:
...When tuning.
The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is
unpleasant. As you tune around, you get tiny blips of sound,
interspersed with long display updates. You basically cannot hear
what you're tuning past.
I just tried commenting out the bit of code that displays the
frequency as you tune. Tuning is much better.
There is still a burst of nasty noise with each encoder *tick*, but
it's short, and you can easily hear what you're tuning past.
Naturally, that's not a real fix. The instant you start tuning,
the frequency display is wrong...and that's just wrong!
What would be a fix? A few things: First of all, we *could* do a
timer thing where we don't bother to display the frequency until we
stop tuning. There was tuning, and now there isn't? Ok, display
where we got to. Still not optimal.
I note that it always updates ALL the digits of the frequency, even
those that haven't changed. It even redisplays the VFO B frequency.
Surely it doesn't need to update all that.
Also - I wonder why on earth the audio pauses or stops or gets
discarded while it writes the display? Surely audio interrupts can
continue during this time....?
- Jerry, KF6VB
|
On 2025-02-01 22:06, K9HZ wrote: Hmmm Stripping functionality out of the radio. Quite the dilemma when you
will likely prefer to "do more" with your radio long-term than less... Stripping functionality was just done as a test. As a solution - doing video in small chunks is just as functional as doing it all at once. And - you gotta get the basics right. THEN you add all the fancy stuff. - Jerry, KF6VB Dr. William J. Schmidt - K9HZ J68HZ 8P6HK ZF2HZ PJ4/K9HZ VP5/K9HZ PJ2/K9HZ
VP2EHZ
Owner - Operator
Big Signal Ranch ¨C K9ZC
Staunton, Illinois
Owner ¨C Operator
Villa Grand Piton ¨C J68HZ
Soufriere, St. Lucia W.I.
Rent it: www.VillaGrandPiton.com
Moderator: North American QRO Group at Groups.IO.
Moderator: Amateur Radio Builders Group at Groups.IO.
email:? bill@...
-----Original Message-----
From: [email protected]
<[email protected]> On Behalf Of jerry-KF6VB
Sent: Saturday, February 1, 2025 11:06 PM
To: [email protected]
Subject: Re: [SoftwareControlledHamRadio] Not Displaying the Frequency....
Things are a little improved. There is a call to tft.fillRect() that erases
the area where the frequency is displayed. Theorizing that audio interrupts
are held back while that's done, I split it up into 5 fillRect()s. So -
clear this little bit, then come up for air and let the audio go. Then
clear the next little bit, then come up for air... etc.
I disabled updating VFO-B, and divided the clear of the current frequency
into 10 mini-clears. Much Better! The audio is still chunky, but you can
hear what you're tuning past.
An obvious next step is to *selectively* rewrite stuff. Why erase and
rewrite stuff that hasn't changed? Keep a string variable "displayed
frequency". Or to make it even simpler, have an array of 8 bytes:
Character displayed in first position, character displayed in second
position - etc. Then erase and rewrite ONLY those characters that have
changed.
- Jerry, KF6VB
On 2025-02-01 20:39, jerry-KF6VB wrote:
I suspect I understand...and it's not good.
I think that SPI requires precise timing, and audio interrupts are
disabled during long video transfers.
Yet... the audio works fine while the spectrum, the S-meter bargraph,
and the waterfall update. Sigh.
- Jerry, KF6VB
On 2025-02-01 18:50, jerry-KF6VB wrote:
...When tuning.
The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is
unpleasant. As you tune around, you get tiny blips of sound,
interspersed with long display updates. You basically cannot hear
what you're tuning past.
I just tried commenting out the bit of code that displays the
frequency as you tune. Tuning is much better.
There is still a burst of nasty noise with each encoder *tick*, but
it's short, and you can easily hear what you're tuning past.
Naturally, that's not a real fix. The instant you start tuning,
the frequency display is wrong...and that's just wrong!
What would be a fix? A few things: First of all, we *could* do a
timer thing where we don't bother to display the frequency until we
stop tuning. There was tuning, and now there isn't? Ok, display
where we got to. Still not optimal.
I note that it always updates ALL the digits of the frequency, even
those that haven't changed. It even redisplays the VFO B frequency.
Surely it doesn't need to update all that.
Also - I wonder why on earth the audio pauses or stops or gets
discarded while it writes the display? Surely audio interrupts can
continue during this time....?
- Jerry, KF6VB
|
On Sat, Feb 1, 2025 at 10:22 PM, jerry-KF6VB wrote:
you gotta get the basics right. THEN you add all the fancy stuff.
Fun stuff!
|
Character displayed in first position, character displayed in second position - etc.? Then
erase and rewrite ONLY those characters that have changed.
Updating the characters used in the frequency display uses very little time. Tracking what has changed and what hasn't changed would likely take more time and updating the entire string. The real time eater is the updating the spectrum/waterfall displays. The waterfall is less of an issue because it's only changing 1x512 pixels on each pass.?
The spectrum display is more difficult because it updates the entire 150x512 pixel area. At each point in that display you must first erase the old pixel and write the new pixel. If they are the same, no write is needed. However, I don't know which is quicker: 1) just rewrite the old and new pixel, or 2) test the two values and only rewrite if they are different.
Since you can "see" which signals are active, I'm less concerned about the audio while tuning than the audio when you stop tuning. Given a finite amount of time, I need to devote my time to those things that don't work than to optimizing those things that do work. After everything is working, then go back and optimize those things that can be improved. The other path is to continue to fix things that aren't working and let those people who think optimizing is so easy make the improvements to those things that are working.
Jack, W8TEE
On Sunday, February 2, 2025 at 12:05:39 AM EST, jerry-KF6VB <jerry@...> wrote:
Things are a little improved.? There is a call to tft.fillRect() that
erases the area where the frequency is displayed.? Theorizing that
audio interrupts are held back while that's done, I split it up into 5
fillRect()s.? So - clear this little bit, then come up for air and let
the
audio go.? Then clear the next little bit, then come up for air... etc.
I disabled updating VFO-B, and divided the clear of the current
frequency
into 10 mini-clears.? Much Better!? The audio is still chunky, but you
can
hear what you're tuning past.
? An obvious next step is to *selectively* rewrite stuff.? Why erase and
rewrite
stuff that hasn't changed?? Keep a string variable "displayed
frequency".? Or to
make it even simpler, have an array of 8 bytes:? Character displayed in
first position, character displayed in second position - etc.? Then
erase and rewrite
ONLY those characters that have changed.
? ? ? ? ? ? ? ? - Jerry, KF6VB
On 2025-02-01 20:39, jerry-KF6VB wrote:
> I suspect I understand...and it's not good.
>
> I think that SPI requires precise timing, and audio interrupts are
> disabled during long video transfers.
>
> Yet... the audio works fine while the spectrum, the S-meter bargraph,
> and the waterfall update.? Sigh.
>
>? ? ? ? ? ? ? ? ? - Jerry, KF6VB
>
>
>
>
> On 2025-02-01 18:50, jerry-KF6VB wrote:
>> ...When tuning.
>>
>>? The tuning of the T41 ( V12, I2C front panel, I2C encoders ) is
>> unpleasant.? As you tune around, you get tiny
>> blips of sound, interspersed with long display updates.? You basically
>> cannot hear what you're tuning past.
>>
>>? I just tried commenting out the bit of code that displays the
>> frequency as you tune.? Tuning is much better.
>> There is still a burst of nasty noise with each encoder *tick*, but
>> it's short, and you can easily hear what you're
>> tuning past.
>>
>>? Naturally, that's not a real fix.? The instant you start tuning, the
>> frequency display is wrong...and that's just wrong!
>>
>>? What would be a fix?? A few things:? First of all, we *could* do a
>> timer thing where we don't bother to display
>> the frequency until we stop tuning.? There was tuning, and now there
>> isn't?? Ok, display where we got to.? Still not optimal.
>>
>>? I note that it always updates ALL the digits of the frequency, even
>> those that haven't changed.? It even
>> redisplays the VFO B frequency.? Surely it doesn't need to update all
>> that.
>>
>>? Also - I wonder why on earth the audio pauses or stops or gets
>> discarded while it writes the display?? Surely
>> audio interrupts can continue during this time....?
>>
>>? ? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB
>>
>>
>>
>
>
>
-- Jack, W8TEE
|
On 2025-02-02 07:25, jjpurdum via groups.io wrote: Character displayed in first position, character displayed in second
position - etc. Then
erase and rewrite ONLY those characters that have changed.
Updating the characters used in the frequency display uses very little
time. *** Yet it is very disruptive to the audio. Why is that? I think it's because interrupts are disabled during SPI transfers. Tracking what has changed and what hasn't changed would likely take more time and updating the entire string. *** Microseconds. Literally zilch. And during the process of this figuring, interrupts are open, and the audio continues. The real time eater is the updating the spectrum/waterfall displays. The waterfall is less of
an issue because it's only changing 1x512 pixels on each pass. *** For some reason - that I don't really understand - the spectrum/waterfall is not a problem. I *suspect* that we are leveraging an internal function of the display to do partial scrolls or block moves. Since you can "see" which signals are active, I'm less concerned about
the audio _while _tuning than the audio when you _stop _tuning. *** Jack, I respectfully disagree. Smooth tuning is VERY important. When I'm zeroing in on an SSB signal or tuning past a CW signal, I want to hear it. Tuning around with my ancient Signal/One is more pleasant than tuning around with the T41 - although once you get there, the T41 receives better. Personally, at least half the time I spend in front of a ham radio is just tuning around. The equipment manufacturers understand this: Just think of all the elaborate main tuning mechanisms that have been used over the years. I think that the tuning can be seriously improved without loading down the radio to any appreciable degree. Just leaving out the update of the inactive VFO is making a big difference. Tuning only affects the main VFO. Why are we erasing and rewriting the inactive one - that doesn't change while tuning? ... let those people who think optimizing is so easy make the improvements to those things that are working. *** Working on it Jack. I am not a guy who takes software challenges lightly. Not any sort of programming genius or cowboy. But I don't think this particular one is too hard. I did embedded software for a living for 20 years, and I developed a pretty good nose for what's hard, and what's not hard. The first most obvious thing is to have a global variable for each display item that tells us *WHAT IS BEING DISPLAYED NOW*? If the new thing to display is the same as what's being displayed now, we don't mess with it. Why change it if it's already right? Working toward minimal audio disruption from display changes will make the tuning useable - but still not nice. To make it *nice* we will need to look at the big fat *tick* that happens at every encoder event. That is IMHO a harder nut to crack. But I remember the old encoder system with the encoders directly connected to a couple of I/O ports as being much smoother. - Jerry, KF6VB
|
On Sunday, February 2, 2025 at 01:13:05 PM EST, jerry-KF6VB <jerry@...> wrote:
On 2025-02-02 07:25, jjpurdum via groups.io wrote:
> Character displayed in first position, character displayed in second
> position - etc.? Then
>
> erase and rewrite ONLY those characters that have changed.
>
> Updating the characters used in the frequency display uses very little
> time.
*** Yet it is very disruptive to the audio.? Why is that?? I think it's
because interrupts are disabled during SPI transfers.
I don't know. The writing of the frequency is done by ShowFrequency(). You might try commenting those calls out to see if one is more "sensitive" than the others and that might lead you to what's really causing the delay.
? Tracking what has changed and what hasn't changed would likely
> take more time and updating the entire string.
*** Microseconds.? Literally zilch.? And during the process of this
figuring,
interrupts are open, and the audio continues.
? The real time eater is
> the updating the spectrum/waterfall displays. The waterfall is less of
> an issue because it's only changing 1x512 pixels on each pass.
*** For some reason - that I don't really understand - the
spectrum/waterfall
is not a problem.
? I *suspect* that we are leveraging an internal function of the display
to do
partial scrolls or block moves. I do use the Block Transfer Engine in the spectrum display code to make it as fast as I can.
> Since you can "see" which signals are active, I'm less concerned about
> the audio _while _tuning than the audio when you _stop _tuning.
*** Jack, I respectfully disagree.? Smooth tuning is VERY important.?
When I'm
zeroing in on an SSB signal or tuning past a CW signal, I want to hear
it.
Tuning around with my ancient Signal/One is more pleasant than tuning
around
with the T41 - although once you get there, the T41 receives better.
I think we have different ideas on what "smooth tuning" is. To me, that means the frequency changes without "jumps". To you, it has something to do with the audio while tuning. Also, as I tune the CW section, I can hear the stations as I tune past them, so maybe we scan the band at vastly different rates.?
? Personally, at least half the time I spend in front of a ham radio is
just
tuning around.? The equipment manufacturers understand this:? Just think
of all
the elaborate main tuning mechanisms that have been used over the years.
? ? I think that the tuning can be seriously improved without loading
down the
radio to any appreciable degree.? Just leaving out the update of the
inactive
VFO is making a big difference.? Tuning only affects the main VFO.? Why
are
we erasing and rewriting the inactive one - that doesn't change while
tuning? That would be easy to omit by just looking at the activeVFO variable. However, as you mentioned, not much time is spent writing the frequency info so I doubt that's main cause of the problem.
... let those people who think optimizing is so easy
> make the improvements to those things that are working.
*** Working on it Jack.? I am not a guy who takes software challenges
lightly.
Not any sort of programming genius or cowboy.? But I don't think this
particular
one is too hard.? I did embedded software for a living for 20 years, and developed a pretty good nose for what's hard, and what's not hard.
I'm glad you are working on it, especially since you think it is an easy fix, and hope others are too. That's why it's Open Source. However, your comments imply that I have an infinite amount of programming time or that your issue is the top priority. It is not. Al and I have been working on the Calibrate routines which are much more urgent. We almost are ready to release the new Calibrate routines and those changes, while perhaps not looking difficult, took over 6 man-months to write and test. Maybe that's a condemnation of our skills, maybe not. It's easy to criticize someone else's work, but to replace it with your own code is a little more difficult. I do hope you can improve it and will share it with all of us. That's what Al and I have been doing for almost 7 years now.
? The first most obvious thing is to have a global variable for each
display item
that tells us *WHAT IS BEING DISPLAYED NOW*?? If the new thing to
display is the
same as what's being displayed now, we don't mess with it.? Why change
it if it's
already right? I agree. But you will have to add code to test the current state of the display and that will take time. The question is, which is faster. Disaggregation should help, but I would like to do it without adding to the globals list...there are already too many globals.
? Working toward minimal audio disruption from display changes will make
the tuning
useable - but still not nice.? Disagree. Your statement asserts that tuning is not usable, but that is false. You may not like it in its current state, but to say it's not usable is simply not true.
To make it *nice* we will need to look at
the big fat
*tick* that happens at every encoder event.? That is IMHO a harder nut
to crack.? But
I remember the old encoder system with the encoders directly connected
to a couple of
I/O ports as being much smoother. The encoders are still directly coupled to the I/O ports. The difference is that the the main tuning is polled rather than driven by an interrupt. I discussed the change why earlier in the week.
? ? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB
| | Re: Not Displaying the Frequency.... |
|
|
I'm
-- Jack, W8TEE
|
On 2025-02-02 11:17, jjpurdum via groups.io wrote: I'm glad you are working on it, especially since you think it is an
easy fix, and hope others are too. That's why it's Open Source.
However, your comments imply that I have an infinite amount of
programming time or that your issue is the top priority. *** Jack, I am not asking you to work on it. I am working on it right now. What on earth gave you the impression that I was asking YOU to work on it? - Jerry, KF6VB
|
Working toward minimal audio disruption from display changes will make
the tuning useable - but still not nice
Why would I not get that impression? To imply something is "unusable" clearly implies that the T41 Project is currently unusable. Since Al and I were the initiators of the project, I think the implication is pretty clear. Why would I not want to work on it if the implication that the current turning isn't usable? I don't know how many others share your assessment of the T41, but I'm glad your working on it. Keep us posted on your progress.
Jack, W8TEE
On Sunday, February 2, 2025 at 02:52:02 PM EST, jerry-KF6VB <jerry@...> wrote:
On 2025-02-02 11:17, jjpurdum via groups.io wrote:
> I'm glad you are working on it, especially since you think it is an
> easy fix, and hope others are too. That's why it's Open Source.
> However, your comments imply that I have an infinite amount of
> programming time or that your issue is the top priority.
*** Jack, I am not asking you to work on it.? I am working on it right
now.
What on earth gave you the impression that I was asking YOU to work on
it?
? ? ? ? ? ? ? ? ? - Jerry, KF6VB
-- Jack, W8TEE
|
On 2025-02-02 12:04, jjpurdum via groups.io wrote: Working toward minimal audio disruption from display changes will
make
the tuning useable - but still not nice
Why would I _not _get that impression? To imply something is
"unusable" clearly implies that the T41 Project is currently unusable. Not the project, just the tuning. It works great once you get where you're going. It's quite an achievement, Jack. You deserve kudos for bringing it to us. Don't be so defensive. - Jerry, KF6VB
|
You're right. Tell you what: I work on being less defensive if you are more thoughtful in your word selection when criticizing the T41 Project. The T41 is not my project. It is the distillation of the effort of hundreds of other people working in concert to make a better radio. To my knowledge, you are the only person out of more than 3200 who have said the tuning is unusable. The tuning IS usable. It's just not working the way you want it to...and that's fine. Just don't chuck the effort by me and others into the dustbin by making a statement that it's unusable. Instead, provide encouragement that suggests a path to make it better without tossing the work into the ashcan.
Jack, W8TEE
On Sunday, February 2, 2025 at 03:16:09 PM EST, jerry-KF6VB <jerry@...> wrote:
On 2025-02-02 12:04, jjpurdum via groups.io wrote:
> Working toward minimal audio disruption from display changes will
> make
> the tuning useable - but still not nice
>
> Why would I _not _get that impression? To imply something is
> "unusable" clearly implies that the T41 Project is currently unusable.
Not the project, just the tuning.? It works great once you get where
you're
going.? It's quite an achievement, Jack.? You deserve kudos for bringing
it
to us.
? Don't be so defensive.
? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB
-- Jack, W8TEE
|
It appears that some of Jerry¡¯s nearly daily posts relate to self inflicted issues. ?I think he is a veteran and talented bit banger so his posts always lead this old (nearly 83) system engineer to look at the code.
I¡¯m an early builder of 4SQRP T41 and never had many problems with how the radio worked until the display blew. ?Assumed it was something I did so bought a new display and everything on the shelf for the last year. ?Found a couple of shorted caps on the
3.3 line on the display so assumed it was likely spikes on the power input but never could find any thing with the scope.
My work at Rockwell-Collins (now Collins Aerospace) focused on determining how comm systems worked on various military aircraft. ?Mostly V/UHF radios but with some HF systems. ?Dealing with customer and corporate ¡°rules¡± could be frustrating. ?It appears
that open architecture on the T41 shouldn¡¯t suffer from that problem; but of course, accountability is unclear. ?
We have gone far beyond the original T41 project and now are hearing about FPGAs. ?Collins had some really smart guys regarding that technology. My question has always been whether you keep the FPGA or transplant the functions into a less volatile and
cheaper device. ?The engineering cost to do that are generally much higher than unit cost savings for low volume military or amateur applications. ?
My hope is that we can establish boundaries between experimental and function paths so old geezers like me can follow.?
73
Jim w0nkn
toggle quoted message
Show quoted text
On Feb 3, 2025, at 9:50?AM, jjpurdum via groups.io <jjpurdum@...> wrote:
?
You're right. Tell you what: I work on being less defensive if you are more thoughtful in your word selection when criticizing the T41 Project. The T41 is not
my project. It is the distillation of the effort of hundreds of other people working in concert to make a better radio. To my knowledge, you are the only person out of more than 3200 who have said the tuning is unusable. The tuning
IS usable. It's just not working the way you want it to...and that's fine. Just don't chuck the effort by me and others into the dustbin by making a statement that it's unusable. Instead, provide encouragement that suggests a path to make it better without
tossing the work into the ashcan.
Jack, W8TEE
On Sunday, February 2, 2025 at 03:16:09 PM EST, jerry-KF6VB <jerry@...> wrote:
On 2025-02-02 12:04, jjpurdum via groups.io wrote:
> Working toward minimal audio disruption from display changes will
> make
> the tuning useable - but still not nice
>
> Why would I _not _get that impression? To imply something is
> "unusable" clearly implies that the T41 Project is currently unusable.
Not the project, just the tuning.? It works great once you get where
you're
going.? It's quite an achievement, Jack.? You deserve kudos for bringing
it
to us.
? Don't be so defensive.
? ? ? ? ? ? ? ? ? ? - Jerry, KF6VB
--
Jack, W8TEE
|
On 2025-02-03 12:34, james jones wrote: My work at Rockwell-Collins (now Collins Aerospace) focused on
determining how comm systems worked on various military aircraft.
Mostly V/UHF radios but with some HF systems. Dealing with customer
and corporate ¡°rules¡± could be frustrating. *** Yeah, the military is a different world. LOADs of paperwork before you write a single line of code. Time card audits... WRT airplanes - according to the guy at the local FSDO ( FAA shop ), I was the second owner on the West Coast to self-install a GNS430 Nav/Comm/GPS unit. Testing stuff was fun; I wrote a program to generate VOR audio from my laptop's sound card. I write lots of posts because I enjoy sharing what I'm doing. The family isn't interested. We have gone far beyond the original T41 project and now are hearing
about FPGAs. Collins had some really smart guys regarding that
technology. My question has always been whether you keep the FPGA or
transplant the functions into a less volatile and cheaper device. *** OH, keep the FPGA, for sure. There just isn't the volume to justify the NRE for an ASIC. I am attempting to learn about FPGAs. I got a little tryit board at a hamfest a few years ago. ( www.webfpga.io ) Reading free info on the Internet, just bought a book on Amazon. Might buy a second tryit board that goes along with the book. ( ) ( ) - Jerry, KF6VB
|
ah yes. That mythical prototyping standard ...
MIL TFD 4.1
"Make It Like The F***ing Drawing, For Once" !
toggle quoted message
Show quoted text
On Mon, Feb 3, 2025 at 09:10 PM, jerry-KF6VB wrote:
*** Yeah, the military is a different world. LOADs of paperwork before
you write a single line of code. Time card audits...
|
K9HZ
jjpurdum