I am the furthest thing from an IT professional; those of you who know me
personally will know how true that is. Still, in a prior life, when I
worked in the banking industry, I was put into the role of user manager of
several highly complex systems (commercial loan, daily/monthly profitability,
etc.) that were in need of re-work.
>From that experience, I remember how difficult it was to get our arms
around systems with high legacy content, past turnover of
designers/analysts/programmers, and extensive interaction with other systems.
Does that sound
familiar?
The possible saving grace in the O II situation might be that we are
"only" dealing with 10K lines of code, rather than millions in the banking
situation. Rather than trying to fix the existing firmware, might it make
more
sense just to treat the O II as an empty hardware platform, and write an
altogether new system?
I don't claim to know the answer. All I can do is ask.
73 Ray W2RS
In a message dated 4/15/2010 2:36:14 P.M. GMT Standard Time,
jmiller1706@cfl.rr.com writes:
I'm going to give the benefit of the doubt now. Could be a number of
things other than inadequate testing before release.
I am wondering if the firmware is finding some uninitialized residual
parameter data in our O2's that isn't in the test radio they have that's
causing our loads to go crazy? I assume a power reset should clear memory
completely but maybe not? Some data values got relocated in flash memory and
when you load it into our radios there is some uncleared data that's hosing
things?
Are they trying to make the software work for both the O2 and the other
radio (Jupiter?). Maybe it works fine for the other one but not the O2?
If it is indeed poor quality control and testing, then that needs to be
cleaned up. If TT does work for the government/defense, they should know
that rigorous, meticulous testing is normally required by the DoD, sometimes
taking weeks and months to complete. Some of that discipline should carry
over to their commercial products.
And someone commented that it takes a good hot-shot programmer. Yes
that's partly true, but with software-defined radio technology, it almost
takes
PhD level theoretical/math understanding of digital signal processing
concepts. Then be able to translate that to firmware. But in reality it
takes
many: A math/DSP guru, a hot shot coder but one who has discipline to
craft good code, and then a good independent test team to wring out the bugs.
I notice that the download appears to be reposted on the TT page...back to
the previous version?
73 Good luck - Jim N4BE
_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec
_______________________________________________
TenTec mailing list
TenTec@contesting.com
http://lists.contesting.com/mailman/listinfo/tentec
|