preferred radio??
12-08-2005, 07:44 PM
#26
Senior Member
My Feedback: (11)
RE: preferred radio??
So now you have two processes: There are different ways of splitting stuff up, but for simplicity let's assume we have:
On Windows - process #1 on processor #1:
[ul][*] Play music, if applicable. [*] Check timer, voltage levels, etc to decide whether to isue a "warning" beep etc. [*] Decide what info is to be displayed on-screen, and send that info to the LCD driver. [*] Poll (touch)screen & other input devices to check for user input ; if user proramming input recieved, modify the configuration data.
[/ul]
On non-Windows OS - process #2 on processor 2:
[ul][*] Poll sticks, switches etc to determine control inputs [*] For each channel: [*] - Look up configuration data to determine settings for reversing, expo, rates, end points etc; [*] - Combining the above data with the stick / switch (etc) position, calculate the output signal component for that channel. [*] Calculate checksum (PCM) [*] Pass signal to RF section for transmission.
[/ul]
Separating this out does improve things, but notice that "configuration data" appears in both processes. i.e it is shared data. Process #1 modifies configuration data (e.g. when you are programming the radio and you select "reverse" to reverse a channel, the fact that the channel has been reversed must be stored). Process #2 reads that same data - if it didn't, then reversing the channel would only reverse what is displayed, not what is actually sent out in the RF link (and that would not be particularly helpful!). This is the crux of the matter. Process 1 (your Windows based one) is permitted to modify the data that process 2 uses for generating the sigmal that is sent out by the RF section - so if process 1 goes nuts (that's a technical term BTW) and writes an incorrect piece of info to that shared data, then process 2 will use that bad data. The fact that we have 2 processes on 2 procesors has certainly removed a subtantial amount of risk, but the fact that the two processes have to communicate with each other means that one can still screw the other up.
Dunno if that helped.
Again, as mentioned in the earlier post that I originally pointed you at, I am not trying to say that a non-Windows OS, or the code that runs on it, will have zero bugs in it - I'm simply trying to debunk the idea that just because there are two processors and only one runs Windows, that a problem on the Windows side can't affect the non-Windows side.
Gordon
On Windows - process #1 on processor #1:
[ul][*] Play music, if applicable. [*] Check timer, voltage levels, etc to decide whether to isue a "warning" beep etc. [*] Decide what info is to be displayed on-screen, and send that info to the LCD driver. [*] Poll (touch)screen & other input devices to check for user input ; if user proramming input recieved, modify the configuration data.
[/ul]
On non-Windows OS - process #2 on processor 2:
[ul][*] Poll sticks, switches etc to determine control inputs [*] For each channel: [*] - Look up configuration data to determine settings for reversing, expo, rates, end points etc; [*] - Combining the above data with the stick / switch (etc) position, calculate the output signal component for that channel. [*] Calculate checksum (PCM) [*] Pass signal to RF section for transmission.
[/ul]
Separating this out does improve things, but notice that "configuration data" appears in both processes. i.e it is shared data. Process #1 modifies configuration data (e.g. when you are programming the radio and you select "reverse" to reverse a channel, the fact that the channel has been reversed must be stored). Process #2 reads that same data - if it didn't, then reversing the channel would only reverse what is displayed, not what is actually sent out in the RF link (and that would not be particularly helpful!). This is the crux of the matter. Process 1 (your Windows based one) is permitted to modify the data that process 2 uses for generating the sigmal that is sent out by the RF section - so if process 1 goes nuts (that's a technical term BTW) and writes an incorrect piece of info to that shared data, then process 2 will use that bad data. The fact that we have 2 processes on 2 procesors has certainly removed a subtantial amount of risk, but the fact that the two processes have to communicate with each other means that one can still screw the other up.
Dunno if that helped.
Again, as mentioned in the earlier post that I originally pointed you at, I am not trying to say that a non-Windows OS, or the code that runs on it, will have zero bugs in it - I'm simply trying to debunk the idea that just because there are two processors and only one runs Windows, that a problem on the Windows side can't affect the non-Windows side.
Gordon
12-08-2005, 07:51 PM
#27
My Feedback: (6)
RE: preferred radio??
But the real crux of the matter is just how probable is it for this scenario to happen (Processor #1 passes goofed up data to #2 and causes a crash). Is it such that one out of every one hundred times you use the radio it happens, or is it such a low probability that interference from sun spots is ten times the worry?
Anyone got a handle on that?
Anyone got a handle on that?
12-08-2005, 07:54 PM
#28
Senior Member
My Feedback: (11)
RE: preferred radio??
Indeed - if the claim was simply that "it isn't all that likely that there will be a problem", then I would not argue the matter since I don't have the means to asses the odds. The only reason I argue the point at all, is the black+white "there are two processors so there's no problem" argument.
12-08-2005, 10:53 PM
#30
My Feedback: (2)
Join Date: Dec 2001
Location: Littleton,
CO
Posts: 1,095
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
ORIGINAL: Gordon Mc
Indeed - if the claim was simply that "it isn't all that likely that there will be a problem", then I would not argue the matter since I don't have the means to asses the odds. The only reason I argue the point at all, is the black+white "there are two processors so there's no problem" argument.
Indeed - if the claim was simply that "it isn't all that likely that there will be a problem", then I would not argue the matter since I don't have the means to asses the odds. The only reason I argue the point at all, is the black+white "there are two processors so there's no problem" argument.
I don't know how in fact the Futaba dual system actually works... but I do know it boots up loading data & also shuts down slowly storing data during the shutdown phase.. just my speculation here mind you, but why would that system scenario need to co-mingle data after boot-up?
One thing I can tell you is Futaba does warn the operator not to interrupt either a boot-up or shutdown command.... switch it ON and wait until the boot-up process is complete... turn it off and leave the switch in the off position until it completes shutdown...
One other point related to the Windows / setup / storage software Futaba says it can be modified at a later date.... I interpret this to mean when enough user's demand a new feature Futaba if they so choose could easily update the software to include the new feature! I like that concept...
The bottom line for for me in all of this is... Futaba was willing to give US more choices NOW.. yes high dollar but it is available now! As a consumer I like that, and I will spend my hard earned money for that! I do agree with you that no one radio system on the market today has everything for everyone..... but I like it when manufactures respond to our needs and wants.
I've heard speculation the JR is as we speak.. is producing the next best radio.... but today my 10X is sorta like your 9Z is nothing but a backup...so when JR comes out with it's new 18 channel radio..(if it does what I demmand of it) maybe my 14MZ will be put on the back shelve.... but until then I'm going to use my new Orange Futaba neck strap and hang my 14MZ on it!
Lee H. DeMary
AMA 36099
12-08-2005, 11:05 PM
#31
Senior Member
My Feedback: (11)
RE: preferred radio??
ORIGINAL: Silver182
but in my simple mind I wonder why would a dual processor system have to run in the way you say.. why couldn't the setup processor load stored data into the a second processor / ram chip during each boot-up... the second processor's operating system then would do only the commands (in ram) and run rock solid until shutdown....
but in my simple mind I wonder why would a dual processor system have to run in the way you say.. why couldn't the setup processor load stored data into the a second processor / ram chip during each boot-up... the second processor's operating system then would do only the commands (in ram) and run rock solid until shutdown....
12-08-2005, 11:41 PM
#32
My Feedback: (2)
Join Date: Dec 2001
Location: Littleton,
CO
Posts: 1,095
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
ORIGINAL: Gordon Mc
If I understand your question correctly, then here's the deal... let's say you make a programming change while you are setting up your model - let's say it's an end-point adjustment, e.g. you're trying to set the correct servo position for "flaps up". Do you want your programming changes to have immediate effect so that you can actually watch the flap move while you adjust it, and can see when you've adjusted it enough ? ... or are you willing to patiently turn the radio on & off for every minute adjustment you make, over & over again ? If you want the former, then that means that the second processor is accepting modified data from the first processor in real-time - not just loading it once at start-up and being done with it.
ORIGINAL: Silver182
but in my simple mind I wonder why would a dual processor system have to run in the way you say.. why couldn't the setup processor load stored data into the a second processor / ram chip during each boot-up... the second processor's operating system then would do only the commands (in ram) and run rock solid until shutdown....
but in my simple mind I wonder why would a dual processor system have to run in the way you say.. why couldn't the setup processor load stored data into the a second processor / ram chip during each boot-up... the second processor's operating system then would do only the commands (in ram) and run rock solid until shutdown....
Understand Gordon, I am not trying to argue with you about this so much as come to a more knowledgeable understanding of what Futaba really did create. I wish a Futaba expert would jump in here and tell us all exactly how the dual processor system works... and why.
I hope Futaba would understand as you and I do.... a twin engine aircraft has twice the chance for an engine failure....
Lee
12-09-2005, 12:04 AM
#33
Senior Member
My Feedback: (11)
RE: preferred radio??
ORIGINAL: Silver182
why couldn't the runtime processor #2 except data changes from box switches applying those changes directly into (Ram)... and then only upon shutdown store those changes back into the setup processor #1?
why couldn't the runtime processor #2 except data changes from box switches applying those changes directly into (Ram)... and then only upon shutdown store those changes back into the setup processor #1?
Again, before anyone thinks I'm forecasting immense doom & gloom for Futaba - let me reiterate once again that I'm not saying that the prospect of a problem in the Windows process causing a ripple-through problem in the transmitted data is a liklihood at all ; No need for anyone to panic & throw their radio away.
For me this is more of an academic argument that "reducing risk" with the 2 process approach does not mean "eliminating risk" as the canned responses suggest. For anyone who doesn't understand the difference - don't panic - just ignore me and go ahead and use your radio. Gordon
12-09-2005, 08:48 AM
#34
My Feedback: (10)
Join Date: Jan 2002
Location: Lakeland,
FL
Posts: 618
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
I suppose that the Futaba folks who spent the better part of four years perfecting the 14MZ platform, and for the most part are considerably smarter than most of us except maybe for Gordon who seems to know just about everythig about anything are a buch of dummies ?!?!?!
So, instead of the usual smokescreen and hand-waving, why don't you refute my assertions with some pertinent facts ?
12-09-2005, 10:36 AM
#36
RE: preferred radio??
If they did it right, then the communications between the two processors is a message passing system with a robust interlocking scheme that (all but) prevents one processor from corrupting the data for the other one. Thus for the Winblows processor to send an erroneous command to change the setup for the current model being flown, it would have to crash (the Winblows processor, not the model 
) such that it could still formulate and authenticate a valid message format. Granted, this would not *eliminate* the potential for failure upon a Winblows crash, but would reduce it to an insignificant level. Note that these techniques are used all the time in critical flight control systems, and I would hope that they (Futaba) took advantage of some of that knowledge.
What really matters is how the system performs in the field. We have a Futaba team member (helis) in our club and he is the most meticulous, cautious flyer I have ever known (and he also has one of the best reliability records I have ever seen too). When the 14MZ was first coming out, he cautioned me about using it in any jets until its record was established. He also had a little concern about the RX problem there were originally having with the system. However, he is now flying the system daily in his contest models in which he has a *large* dollar and time investment and is making very positive comments about the system's performance and reliability. Its getting close to the point where I'm starting to think about squirreling away a couple of grand for one for myself - especially when I realize how many channel expanders I'm going to need to get all of the functions on my Panther onto my 9CHP (or a 10X for that matter)...
Bob
) such that it could still formulate and authenticate a valid message format. Granted, this would not *eliminate* the potential for failure upon a Winblows crash, but would reduce it to an insignificant level. Note that these techniques are used all the time in critical flight control systems, and I would hope that they (Futaba) took advantage of some of that knowledge.What really matters is how the system performs in the field. We have a Futaba team member (helis) in our club and he is the most meticulous, cautious flyer I have ever known (and he also has one of the best reliability records I have ever seen too). When the 14MZ was first coming out, he cautioned me about using it in any jets until its record was established. He also had a little concern about the RX problem there were originally having with the system. However, he is now flying the system daily in his contest models in which he has a *large* dollar and time investment and is making very positive comments about the system's performance and reliability. Its getting close to the point where I'm starting to think about squirreling away a couple of grand for one for myself - especially when I realize how many channel expanders I'm going to need to get all of the functions on my Panther onto my 9CHP (or a 10X for that matter)...
Bob
12-09-2005, 10:55 AM
#37
Senior Member
My Feedback: (11)
RE: preferred radio??
ORIGINAL: rhklenke
If they did it right, then the communications between the two processors is a message passing system with a robust interlocking scheme that (all but) prevents one processor from corrupting the data for the other one. Thus for the Winblows processor to send an erroneous command to change the setup for the current model being flown, it would have to crash (the Winblows processor, not the model ) such that it could still formulate and authenticate a valid message format. Granted, this would not *eliminate* the potential for failure upon a Winblows crash, but would reduce it to an insignificant level. Note that these techniques are used all the time in critical flight control systems, and I would hope that they (Futaba) took advantage of some of that knowledge.
If they did it right, then the communications between the two processors is a message passing system with a robust interlocking scheme that (all but) prevents one processor from corrupting the data for the other one. Thus for the Winblows processor to send an erroneous command to change the setup for the current model being flown, it would have to crash (the Winblows processor, not the model
) such that it could still formulate and authenticate a valid message format. Granted, this would not *eliminate* the potential for failure upon a Winblows crash, but would reduce it to an insignificant level. Note that these techniques are used all the time in critical flight control systems, and I would hope that they (Futaba) took advantage of some of that knowledge.
BTW, the failure description you outline above seems to miss a crucial point - in order to get "bad data" passed on to the second process it is not necessary for a crash and a freak corruption that just happens to be a valid msg format ; a crash is not the only failure mode that needs to be considered - getting stuck in a loop etc is a common failure such that the process is still running, just not running the way that was wanted, and since the Windows process must, by definition, have the algorithm for generating valid messages built into it, it clearly has the wherewithall to generate valid packages. Formats, CRC checks, etc., all can protect against accepting a badly formed package, but don't protect against accepting a package that is correctly formatted but generated from incorrect data. In a way, it's like having a henhouse that is secured with locks... but the fox has the key to the lock !
Later,
Gordon
12-09-2005, 11:03 AM
#38
Senior Member
Join Date: Jan 2005
Location: Grand Rapids, MI
Posts: 173
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
Gordon I totally agree and understand everything you're saying.
I'd like to point out that when windows crashes it usually is the result of some kind of user error. Kind of like expecting a Pinto to keep pace with a Porsche. One thing that this "winblows" based Tx has going for it is that it is not asking a lot of the processor or OS. I'm not saying it still won't happen, but there are a lot more variables removed from our normal computers and PDAs.
I wonder if it is based on the same version of Embedded Windows CE that Crestron used in the TPMC-10. Having been in the home control processor business for over 30 years it was not until recently that the embedded version of Windows XP was released that they finally started using it in their touch panels. [link=http://crestron.com/features/isys_io/]www.crestron.com[/link] Granted they are not using windows to control entire homes (thank god). But I'm not sure Windows is necessarily the flawed aspect.
I guess at the end of the day it all boils down to what you do with it. Bad code running on a great OS will run bad.
I for one am still interested in getting a 14MZ.
Mark
I'd like to point out that when windows crashes it usually is the result of some kind of user error. Kind of like expecting a Pinto to keep pace with a Porsche. One thing that this "winblows" based Tx has going for it is that it is not asking a lot of the processor or OS. I'm not saying it still won't happen, but there are a lot more variables removed from our normal computers and PDAs.
I wonder if it is based on the same version of Embedded Windows CE that Crestron used in the TPMC-10. Having been in the home control processor business for over 30 years it was not until recently that the embedded version of Windows XP was released that they finally started using it in their touch panels. [link=http://crestron.com/features/isys_io/]www.crestron.com[/link] Granted they are not using windows to control entire homes (thank god). But I'm not sure Windows is necessarily the flawed aspect.
I guess at the end of the day it all boils down to what you do with it. Bad code running on a great OS will run bad.
I for one am still interested in getting a 14MZ.
Mark
12-09-2005, 11:23 AM
#39
Senior Member
My Feedback: (11)
RE: preferred radio??
ORIGINAL: mdelzer
Gordon I totally agree and understand everything you're saying.
<snip>
I for one am still interested in getting a 14MZ.
Mark
Gordon I totally agree and understand everything you're saying.
<snip>
I for one am still interested in getting a 14MZ.
Mark
Like I said earlier, no radio is perfect. Hope you enjoy your 14MZ when you get it.
Gordon
12-09-2005, 11:27 AM
#40
My Feedback: (14)
Join Date: May 2002
Location: Gales Ferry, CT
Posts: 4,878
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
You don't need two operating systems running to crash a plane. I am quite positive you can have a problem with any processor, JR, Futaba, Multiplex, etc. All it takes is an intermittent fart at the wrong time. One that only shows it's self every few hours and lasts for a few minutes but then clears after you pick up the pieces. [:@]
Splitting out the processes may even be an improvement.
Splitting out the processes may even be an improvement.
12-09-2005, 11:53 AM
#42
Join Date: Apr 2004
Location: Southam, UNITED KINGDOM
Posts: 988
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
In my real job of very high value printing devices, we chose to use Windows operating systems. Now you could probably buy Futuaba for our yearly sales value of these products, and yet we still had problems with the operating systems, with bugs and stuff crashing, and these were time critical devices for clients.
The point is, you can have lots of processors, but if an error occurs, it will affect something. If you think of mirrored systems and dual processors in server technologies, they painstakingly follow each other, but when one falls over, the recovery is "just before" it falls over on the other system. Anyone used backup routines to find out they have just the same error!?[X(] I have!!!
I think Gordon is doing a good job of de mything, 2 processors must be safe. I am sure they are very clever people at Futuba, and so the same is possibly true at Microsoft, but nothing is perfect.
To my mind, Windows is not appropriate for our transmitters, much better off with operating systems that are not trying to give lots of user intervention and non related features, like Unix and other machine code related programs.
None of this makes the MZ anything other than a superlative ground breaking product, that does offer increased function and channels. But I wont buy one as it has many functions that make use of an idling processor, that one appears to have to pay for!!!
As my needs grow, I will be following JR's progress with interest, and see what they come up with but for now, and for ME, the PCM10 is complex enough, functional enough and powerful enough. That said its just off for repair as I dropped it[:@]
I'm also sure much of this was previously covered in a really good thread when the MZ14 was first launched, including jibes about hte blue screen of detah, to which I have not heard or seen any reports!!!!!
Gazzer
Gazzer
The point is, you can have lots of processors, but if an error occurs, it will affect something. If you think of mirrored systems and dual processors in server technologies, they painstakingly follow each other, but when one falls over, the recovery is "just before" it falls over on the other system. Anyone used backup routines to find out they have just the same error!?[X(] I have!!!
I think Gordon is doing a good job of de mything, 2 processors must be safe. I am sure they are very clever people at Futuba, and so the same is possibly true at Microsoft, but nothing is perfect.
To my mind, Windows is not appropriate for our transmitters, much better off with operating systems that are not trying to give lots of user intervention and non related features, like Unix and other machine code related programs.
None of this makes the MZ anything other than a superlative ground breaking product, that does offer increased function and channels. But I wont buy one as it has many functions that make use of an idling processor, that one appears to have to pay for!!!
As my needs grow, I will be following JR's progress with interest, and see what they come up with but for now, and for ME, the PCM10 is complex enough, functional enough and powerful enough. That said its just off for repair as I dropped it[:@]
I'm also sure much of this was previously covered in a really good thread when the MZ14 was first launched, including jibes about hte blue screen of detah, to which I have not heard or seen any reports!!!!!
Gazzer
Gazzer
12-09-2005, 12:15 PM
#43
Senior Member
Join Date: Jan 2005
Location: Grand Rapids, MI
Posts: 173
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
ORIGINAL: Gazzer
I'm also sure much of this was previously covered in a really good thread when the MZ14 was first launched, including jibes about hte blue screen of detah, to which I have not heard or seen any reports!!!!!
Gazzer
Gazzer
I'm also sure much of this was previously covered in a really good thread when the MZ14 was first launched, including jibes about hte blue screen of detah, to which I have not heard or seen any reports!!!!!
Gazzer
Gazzer
Mark
12-09-2005, 12:19 PM
#44
Join Date: Apr 2004
Location: Southam, UNITED KINGDOM
Posts: 988
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
LOL
Boy have we had fun recently with embedded Xp on a RIP.[:@][&o][&:]
Come the reovlution I am sure Bill gates will be first aginst the wall, remember his famous quote "64k shoud be enough for anyone"!!!!
Gazzer
Boy have we had fun recently with embedded Xp on a RIP.[:@][&o][&:]
Come the reovlution I am sure Bill gates will be first aginst the wall, remember his famous quote "64k shoud be enough for anyone"!!!!
Gazzer
12-09-2005, 12:27 PM
#45
Senior Member
My Feedback: (11)
RE: preferred radio??
ORIGINAL: Gazzer
LOL
Boy have we had fun recently with embedded Xp on a RIP.[:@][&o][&:]
Come the reovlution I am sure Bill gates will be first aginst the wall, remember his famous quote "64k shoud be enough for anyone"!!!!
Gazzer
LOL
Boy have we had fun recently with embedded Xp on a RIP.[:@][&o][&:]
Come the reovlution I am sure Bill gates will be first aginst the wall, remember his famous quote "64k shoud be enough for anyone"!!!!
Gazzer
Yeah, though to be fair to Uncle Bill, he's in distinguished company when he makes quotes like that...
"I think there is a world market for maybe 5 computers." : Thomas Watson, head of IBM, 1943
"There is no reason anyone would want a computer in their home." : Ken Olson, President, Chairman, and Founder of Digital Equipment Corporation, 1977
"Radio has no future.": Lord Kelvin, Physicist and President of the Royal Society, 1897
12-09-2005, 02:02 PM
#47
RE: preferred radio??
ORIGINAL: Gordon Mc
[snip]
BTW, the failure description you outline above seems to miss a crucial point - in order to get "bad data" passed on to the second process it is not necessary for a crash and a freak corruption that just happens to be a valid msg format ; a crash is not the only failure mode that needs to be considered - getting stuck in a loop etc is a common failure such that the process is still running, just not running the way that was wanted, and since the Windows process must, by definition, have the algorithm for generating valid messages built into it, it clearly has the wherewithall to generate valid packages. Formats, CRC checks, etc., all can protect against accepting a badly formed package, but don't protect against accepting a package that is correctly formatted but generated from incorrect data. In a way, it's like having a henhouse that is secured with locks... but the fox has the key to the lock !
Later,
Gordon
[snip]
BTW, the failure description you outline above seems to miss a crucial point - in order to get "bad data" passed on to the second process it is not necessary for a crash and a freak corruption that just happens to be a valid msg format ; a crash is not the only failure mode that needs to be considered - getting stuck in a loop etc is a common failure such that the process is still running, just not running the way that was wanted, and since the Windows process must, by definition, have the algorithm for generating valid messages built into it, it clearly has the wherewithall to generate valid packages. Formats, CRC checks, etc., all can protect against accepting a badly formed package, but don't protect against accepting a package that is correctly formatted but generated from incorrect data. In a way, it's like having a henhouse that is secured with locks... but the fox has the key to the lock !
Later,
Gordon
The point is, the 14 MZ is proving its reliability in the field more every day (which is all that really matters, academic discussions aside) and it will soon be considered (if its not already) as reliable as the 9C, 9Z, 10X and that will be of great benefit to us. I work a lot with the 10X, and, like the 9C and 9Z, it is an extremely reliable radio and it does have 10 fully proportional channels (unlike the Futaba's which have 8 proportional and 1 on/off channel), but the programming of the 10X is awfull compared to any of the newer radios and its long since been due for an update...
Personally, I would no longer recommend the investment of a grand for a 10X today to anyone getting into jets. I'd spend $300 or so for a reliable 9 channel radio from either Futaba or JR, and wait for the 14MZ to come completely out from under its "teething problems". I know that the Multiplex and Graupner are out there, but for me, there's not enough of a user base in the US to recommend someone getting one (or getting one myself). Just my opinion of course...
Bob
12-09-2005, 06:48 PM
#48
My Feedback: (1)
Join Date: Dec 2001
Location: Fort Wayne, IN
Posts: 3,759
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
I think your Futaba TX with the Windows OS will be just fine as long as you don't hook it to the internet so some hacker can load it down with a few of their viruses!!!!!!!!!LOL
12-09-2005, 07:47 PM
#49
Senior Member
My Feedback: (3)
Join Date: Nov 2002
Location: Rahway,
NJ
Posts: 1,063
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
I can not speak for the developers that that did the coding for the 14MZ, but i can say with some knowledge of being a systems analyst that i have done a lot of field testing of code that worked perfectly for a set period of time and under certain scenario's would fail. Not every scenario can be tested in the lab, it is us the consumer that gets the pleasure of performing a good part of the stress testing. Why do you think MS comes out with an update at least once a month......
Food for thought
Alan
Food for thought
Alan
12-10-2005, 09:02 AM
#50
My Feedback: (2)
Join Date: Dec 2001
Location: Littleton,
CO
Posts: 1,095
Likes: 0
Received 0 Likes
on
0 Posts
RE: preferred radio??
[quote]ORIGINAL: rhklenke
All I can say is my 14MZ has been perfect... out of the box... I did a three stage check before flying it, as I do all new radio equipment..
1. Swamp check, must past 1:10 foot interfere check..
2. Vibration test Rec....
3. Temp check Rec. in the frig overnight...
Once it passed all three of these tests, I range checked it Baseline & Power on.. installed it in a high performance elec. & flew it for a few weekends.
After about a three weekend flight check which included setting fail-safe controls for a snap-roll.. full deflection elev, rud, aileron and it worked without a hiccup... I then installed it in my BVM BobCat, did the Baseline & Powered up range check again comparing distances... OK'd it.. and have been flying it ever since!
This last summer I flew my BobCat & the 14MZ alot.. even flew it at an EAA fly-in at Front Range Airport for a demo flight here in the Denver area. It was a grand opening for the airports new FAA control tower & 10,000 foot runway. FAA airspace was closed so I let the BobCat loose.. Vertical performance, speed <200, and some aerobatics
The bottom line is for me the 14MZ is now my number one radio! Not because I am a Futaba lover cause I'm not.. I've never been locked to a brand name, it's all in how it performs.
Lee H. DeMary
AMA 36099
ORIGINAL: Gordon Mc
[snip]
BTW, the failure description you outline above seems to miss a crucial point - in order to get "bad data" passed on to the second process it is not necessary for a crash and a freak corruption that just happens to be a valid msg format ; a crash is not the only failure mode that needs to be considered - getting stuck in a loop etc is a common failure such that the process is still running, just not running the way that was wanted, and since the Windows process must, by definition, have the algorithm for generating valid messages built into it, it clearly has the wherewithall to generate valid packages. Formats, CRC checks, etc., all can protect against accepting a badly formed package, but don't protect against accepting a package that is correctly formatted but generated from incorrect data. In a way, it's like having a henhouse that is secured with locks... but the fox has the key to the lock !
Later,
Gordon
[snip]
Personally, I would no longer recommend the investment of a grand for a 10X today to anyone getting into jets. I'd spend $300 or so for a reliable 9 channel radio from either Futaba or JR, and wait for the 14MZ to come completely out from under its "teething problems". I know that the Multiplex and Graupner are out there, but for me, there's not enough of a user base in the US to recommend someone getting one (or getting one myself). Just my opinion of course...
Bob
[snip]
BTW, the failure description you outline above seems to miss a crucial point - in order to get "bad data" passed on to the second process it is not necessary for a crash and a freak corruption that just happens to be a valid msg format ; a crash is not the only failure mode that needs to be considered - getting stuck in a loop etc is a common failure such that the process is still running, just not running the way that was wanted, and since the Windows process must, by definition, have the algorithm for generating valid messages built into it, it clearly has the wherewithall to generate valid packages. Formats, CRC checks, etc., all can protect against accepting a badly formed package, but don't protect against accepting a package that is correctly formatted but generated from incorrect data. In a way, it's like having a henhouse that is secured with locks... but the fox has the key to the lock !
Later,
Gordon
[snip]
Personally, I would no longer recommend the investment of a grand for a 10X today to anyone getting into jets. I'd spend $300 or so for a reliable 9 channel radio from either Futaba or JR, and wait for the 14MZ to come completely out from under its "teething problems". I know that the Multiplex and Graupner are out there, but for me, there's not enough of a user base in the US to recommend someone getting one (or getting one myself). Just my opinion of course...
Bob
1. Swamp check, must past 1:10 foot interfere check..
2. Vibration test Rec....
3. Temp check Rec. in the frig overnight...
Once it passed all three of these tests, I range checked it Baseline & Power on.. installed it in a high performance elec. & flew it for a few weekends.
After about a three weekend flight check which included setting fail-safe controls for a snap-roll.. full deflection elev, rud, aileron and it worked without a hiccup... I then installed it in my BVM BobCat, did the Baseline & Powered up range check again comparing distances... OK'd it.. and have been flying it ever since!
This last summer I flew my BobCat & the 14MZ alot.. even flew it at an EAA fly-in at Front Range Airport for a demo flight here in the Denver area. It was a grand opening for the airports new FAA control tower & 10,000 foot runway. FAA airspace was closed so I let the BobCat loose.. Vertical performance, speed <200, and some aerobatics
The bottom line is for me the 14MZ is now my number one radio! Not because I am a Futaba lover cause I'm not.. I've never been locked to a brand name, it's all in how it performs.
Lee H. DeMary
AMA 36099
