Kiwi's XPS test results are up.

[JimDrew]

	Quote: Originally Posted by Daemon
	Short answer, using the current 2.4Ghz XBee modules. No. Because it is two way, the satellite receivers are at best, dumb, and at worst a liability. They can't transmit ACKs without interfering with the main Rx's ACKs (you'd actually be creating multipath interference at the source) so if the main Rx antenna is blocked, and the satellite receiver antennas are not, the Tx will still think it has lost the link, even though the Rx is still getting signals from its satellites. That'd be ok, if it was meant to always be a one way system, but it's not.

People forget that we use only the XBEE hardware. The firmware is our own, and if you look at the chipset used with the XBEE, you can clearly see that multiple receivers can be used and the ACKs will not collide.

	Quote: Originally Posted by Daemon
	As for hopping, it can be done, but it's always going to be *slow*, again because the two way nature gets in the way and it's tough for both ends of a two way link to know for sure if the link is 100% broken or only 50% broken, and you risk more by hopping when it's 50% broken than you would by staying put.

That is completely wrong. We can support 5ms frames, complete with ACKs and change frequencies every single frame. Frames are typically every 22ms. Think that is slow, well I have some news for you. Spektrum frequency hops every frame between two frequencies. They don't "lock on" to two channels as they claim. Every 22ms, the data is transmitted to the other frequency. Interesting too, since their FCC ID clearly shows their system to be a DSSS configuration. Part 15.247 clearly states that any device changing frequencies faster than once every 400ms/dwell is required to occupy no fewer than 15 channels. Hopping every frame is not legal by these rules. When I added the "hop on saturate to foil the bench testers code", I asked for clarification from the FCC on the hopping speed and we either have to transmit with a psuedo-random 15 frequency algorithm, or we can not hop faster than roughly once every 300ms, which is actually faster than the 450ms spacing we had in the original hopping code. So, it was a benefit to look into this.

[KrisW]

	Quote: Originally Posted by JimDrew
	People forget that we use only the XBEE hardware. The firmware is our own, and if you look at the chipset used with the XBEE, you can clearly see that multiple receivers can be used and the ACKs will not collide. That is completely wrong. We can support 5ms frames, complete with ACKs and change frequencies every single frame. Frames are typically every 22ms. Think that is slow, well I have some news for you. Spektrum frequency hops every frame between two frequencies. They don't "lock on" to two channels as they claim. Every 22ms, the data is transmitted to the other frequency. Interesting too, since their FCC ID clearly shows their system to be a DSSS configuration. Part 15.247 clearly states that any device changing frequencies faster than once every 400ms/dwell is required to occupy no fewer than 15 channels. Hopping every frame is not legal by these rules. When I added the "hop on saturate to foil the bench testers code", I asked for clarification from the FCC on the hopping speed and we either have to transmit with a psuedo-random 15 frequency algorithm, or we can not hop faster than roughly once every 300ms, which is actually faster than the 450ms spacing we had in the original hopping code. So, it was a benefit to look into this.

Is it possible that Spektrum has two transmitter sections in each module, retransmitting the same data and encoding, but on two different frequencies? Seems like every Spektrum receiver I've ever seen has two antennae. . possibly two receiver sections per unit??

hmmmmm. . something to think about, eh? Not that I know. . just that the possibility seems plausible if there are laws and such against single transmitters doing certain things.

After all this time, I'd expect JD to have something better to throw our way than "but. . but. . but SPEKTRUM. . .etc etc etc. . . ."

so, the question then remains, IF XPS is so. . . agile. . .WHY doesn't it ever hop??? AndIF you coulduse multiple receivers. . WHY don't you do it?

Anyone ever seen a video proving that it can, or does? I certainly haven't.

[aviti]

	Quote: Originally Posted by JimDrew
	People forget that we use only the XBEE hardware. The firmware is our own, and if you look at the chipset used with the XBEE, you can clearly see that multiple receivers can be used and the ACKs will not collide. That is completely wrong. We can support 5ms frames, complete with ACKs and change frequencies every single frame. Frames are typically every 22ms. Think that is slow, well I have some news for you. Spektrum frequency hops every frame between two frequencies. They don't "lock on" to two channels as they claim. Every 22ms, the data is transmitted to the other frequency. Interesting too, since their FCC ID clearly shows their system to be a DSSS configuration. Part 15.247 clearly states that any device changing frequencies faster than once every 400ms/dwell is required to occupy no fewer than 15 channels. Hopping every frame is not legal by these rules. When I added the "hop on saturate to foil the bench testers code", I asked for clarification from the FCC on the hopping speed and we either have to transmit with a psuedo-random 15 frequency algorithm, or we can not hop faster than roughly once every 300ms, which is actually faster than the 450ms spacing we had in the original hopping code. So, it was a benefit to look into this.

If you can't dazzle them with brilliance, baffle them with BS. Thanks for clearing all this up Jim. I'll put my Spektrum gear up for sale and convert to XPS immediately if not sooner.

[JimDrew]

	Quote: Originally Posted by KrisW
	so, the question then remains, IF XPS is so. . . agile. . .WHY doesn't it ever hop??? AndIF you coulduse multiple receivers. . WHY don't you do it? Anyone ever seen a video proving that it can, or does? I certainly haven't.

The reality is that we don't fly models on a bench, and certainly not within inches of a WiFi device hooked to a computer. The power output required to cause what is demonstrated here while flying would cause the saturation of the entire 2.4GHz band (above and below 2.4GHz), and not a single frequency. A good example of this is the flying field in Davis, CA. The Nexrad that sits just a few miles away from the field transmits on 2.7GHz, yet 750,000 watts appears to bleed over so badly that none of the 2.4GHz systems will work. They won't even connect if they are within a mile of the tower. Hopping when there is nowhere to go is a bit foolish, and that the reality of the environment that we use our radio systems in.

According to the FCC, you are not allowed to even attempt to transmit data if the noise floor exceeds a certain threshold (-36 db). In the bench testing that has been done, our system may not be prevented from receiving data, it may no longer be transmitting data. I just read the forum here, and I ordered two of the Airhorns. We use 2.4GHz video transmitters for testing here now. We have a couple of more issues to wrap up with the FCC and we can release the new firwmare that will make the bench testers happy. A lot of work for a simple show. I can't wait to see what's next.

The current hopping algorithm was created by using real world tests to generate a noise pattern that must occur. I am not sure how you would generate this pattern with the Airhorn, and since I am not yet familiar with the Airhorn, I can't speculate how you would accomplish it. I do know that if you take off on channel 1 and you land on channel 7 (as some have already reported), then obviously something must have occurred. If the system didn't hop at all, we wouldn't have a few angry customers who used 2.4GHz video cameras on board that were remotely activated. The system can hop on to the same frequency range that the camera uses while it is off. Switching it on, yields a lock out since there is a complete saturation of the frequency, and the receiver is programmed not to move in these cases as typically enough power to cause the lockout means the entire band is wiped out. The solution: don't use a 2.4GHz camera with any 2.4GHz system.

Our antenna's spherical radiation pattern (recently confirmed again with anechoic chamber tests) provides an omni-directional antenna. With this antenna and our bi-directional communication, we have not found a genuine need for multiple receivers. However, to appease the masses, we will be releasing satellite receivers. These are part of our telemetry package, which allows up to 64 devices to be connected to the telemetry port. So, you could have up to 65 receivers in your aircraft. This does not add "antenna diversity" (which everyone claims to have a patent pending for), it adds redundant receivers in case of primary receiver failure.

[klhoard]

.
.
I think you're yelling into an empty stadium, JD. . .
.
.

[XJet]

	Quote: Originally Posted by JimDrew
	The reality is that we don't fly models on a bench, and certainly not within inches of a WiFi device hooked to a computer.

Sometimes the only way to test for certain conditions in a repeatable scenario is to emulate potential "real-world" situations on the bench. You don't do that?

	Quote:
	The power output required to cause what is demonstrated here while flying would cause the saturation of the entire 2.4GHz band (above and below 2.4GHz), and not a single frequency.

I strongly disagree.

	Quote:
	A good example of this is the flying field in Davis, CA. The Nexrad that sits just a few miles away from the field transmits on 2.7GHz, yet 750,000 watts appears to bleed over so badly that none of the 2.4GHz systems will work. They won't even connect if they are within a mile of the tower. Hopping when there is nowhere to go is a bit foolish, and that the reality of the environment that we use our radio systems in.

Have you actually determined if this is due to sidebands on the 2.7GHz signal or simply front-end overload in the receivers?

	Quote:
	According to the FCC, you are not allowed to even attempt to transmit data if the noise floor exceeds a certain threshold (-36 db).

That's odd -- because testing seems to indicate that XPS *does* continue to transmit, even when noise levels far exceed the -36dB you quote. Does that mean you're not FCC-compliant?

	Quote:
	The current hopping algorithm was created by using real world tests to generate a noise pattern that must occur

Are these "real world tests" related to the ones you did before claiming that a transmitter dipole was completely unnecessary?

	Quote:
	If the system didn't hop at all, we wouldn't have a few angry customers who used 2.4GHz video cameras on board that were remotely activated. The system can hop on to the same frequency range that the camera uses while it is off. Switching it on, yields a lock out since there is a complete saturation of the frequency, and the receiver is programmed not to move in these cases as typically enough power to cause the lockout means the entire band is wiped out.

You keep making this claim and I continue to refute it. Your "real world" seems decidedly different to the one I live in and the one that many folks have to fly in Jim.

And if XPS's hopping algorithm is so good -- why, in the tests conducted here, did XPS stop working when JR/Spektrum and FASST coped without any problems? This must surely be the single most important question that needs to be answered. You won't try to dodge that one will you?

	Quote:
	Our antenna's spherical radiation pattern (recently confirmed again with anechoic chamber tests) provides an omni-directional antenna.

Please tell me where we can see the 3-dimensional plots of this pattern. I've asked for this data from you I don't know how many times but all you've offered is the 2D plots from Maxstream. If you now have that data (which you seem to be claiming) I'm sure we'd all like to see it for ourselves -- otherwise it's hearsay.

	Quote:
	With this antenna and our bi-directional communication, we have not found a genuine need for multiple receivers.

So how do you cope with shadowing in a large model where it's impossible to position the receiver so that the signal isn't going to be blocked by a major metal or composite structure from some angles. The antenna's radiation pattern doesn't matter one sack of beans if it's shadowed and the same goes for resending the data. If the receiver remains in the shadow, it will not receive the data and it's "lockout time".

	Quote:
	However, to appease the masses, we will be releasing satellite receivers.

Why don't I believe that this is the sole reason?

	Quote:
	These are part of our telemetry package, which allows up to 64 devices to be connected to the telemetry port. So, you could have up to 65 receivers in your aircraft. This does not add "antenna diversity" (which everyone claims to have a patent pending for), it adds redundant receivers in case of primary receiver failure.

So what you're saying then (if it's not diversity) is that the secondary receiver(s) will not function unless the primary receiver fails (otherwise it *is* diversity).

Will you be able to run telemetry *without* a satellite receiver?

Can you give us a timeline?

Can you also elaborate on the situation in Europe? Graupner appears to have been giving quite a few refunds and taking back XPS gear with increasing regularity there. Are there special issues in this market?

[zoomer260]

Shock and Awe. WOW !! Mr. Drew please show us how XPS hops. That is how this thread came to be. And how a single channel 2.4 system can be any better than half of one that uses two ? Or more ?

I have not been able to convert yet and I was all over your advertisements which are hard to find these days.

You want my money defend your product.

[Reckless Loony]

Here is something people might find interesting.

http://www.automags.org/forums/showthread.php?t=116538

The interview link is dead but reading that forum one notices that JD managed to get 3 degrees while he was still in high school. If the guy really did earn those degrees instead of buying them over the Internet including a degree in Electronic Engineering then why did he go on about the spherical radiation pattern?

This is the only way to get a spherical radiation pattern

http://en.wikipedia.org/wiki/Isotropic_radiator


There is a saying “A leopard can’t change his spots”. There is also Dr Phil who said (not exact quote) ‘A persons past behaviour is an indicator of future behaviour’

Here is a small snippet of JD’s past.

http://www.emaculation.com/forum/vi...0ac31a6838451ac

http://www.pbnation.com/showthread.php?p=26376318

http://www.automags.org/forums/showthread.php?t=116914

http://www.automags.org/forums/showthread.php?t=203358


Note his two previous businesses were Microcode Solutions and Wicked Air Sportz.

That should give an idea in the direction XPS is headed.


Now as for this hopping thing

The user manual for the Digi 2.4Ghz RF modules that JD uses

http://ftp1.digi.com/support/documen...5.4_v1.xAx.pdf

Now look at the XPS website

http://www.xtremepowersystems.net/xtremelink.php

“predictive frequency hopping technique”

Predictive?? You mean those modules have crystal ball technology or is there a clairvoyant circuit? How the hell are you supposed to be able to predict when a 2.4Ghz device gets turned on and off?

Try this next time your at the flying field. Get a pad and pen and sit down in the pits. Watch your fellow modellers turn on their radios and note this down in the pad also note those that are turning off radios. Pretend all these radios are 2.4Ghz sets. Once you have made a nice list (a table) see if that helps you in determining (predicting) those that are about to turn on their radio next and those that are going to turn off their radio next. You will find it will be pretty much random unless of coarse it is close to lunch and then most club members will stop flying for the club lunch barbecue.

So how are these Digi 2.4Ghz modules able to read/monitor the noise level of the 2.4Ghz ISM band? Well on page 32 you can see the diagnostic commands.

You can use the DB command to find out the received signal strength.

Remember people these modules are designed for a PC RF networking (LAN) application therefore there would be a number of these RF modules communicating to each other. This then brings up the energy scan ED command. This is where the coordinator module (master module) initiates the other RF modules to send to it the signal strength value that they each have been receiving. Since these modules are being used in an RC application there is only two of these modules in use one in the Tx and the other in the Rx on the aircraft. Presumably there won’t be anybody trying to fly two or more aircraft at the same time using just the one Tx. Therefore the energy scan is completely useless in an RC application.

Back to the DB command the signal strength value returned is for the current channel the Tx and Rx modules are currently on. In order to establish what noise levels are on the other 12 channels it is therefore necessary to change channels in order to get signal strength readings for all channels not only that but it would have to be done continuously in order to continuously monitor the noise levels. This channel changing is accomplished by the CH (channel command) and AS (active scan) command. The coordinator (master) module sets the channel in the case of XPS it is the Rx (according to JD) and then the Tx has to find it using the AS command. The problem is active scan takes a bloody long time to do. Page 51 gives the equation as well as the duration of time it takes. Do note that AS is used in conjunction with the SD (scan duration) command. If SD is set for the minimum value there is a good chance the Tx will fail to find the Rx especially if the noise level is getting high. It should be pointed out that while the modules are in command mode there is no data flow in other words the Tx is no longer transmitting stick data to the Rx. Even if SD is set to 0 the time taken to perform the scan is 180ms which means at least 9 lost frames of data which will be noticed when your flying your aircraft. JD has stated that the modules wont switch frequency until necessary and this is the reason why. You can’t have the modules hopping about the channels in order to monitor the noise level of the other channels because you would be losing at least 9 frames of data every time they changed channels, which would make for crappy control of the aircraft.

Therefore this proves that the statement “predictive frequency hopping technique” is a load of crap.

BTW page 20 of the manual describes the 5 modes of operation of the modules and how they are entered into.


But wait there is more. Here are some actual in the field failures.

http://www.rcgroups.com/forums/showthread.php?t=815081

http://www.rcgroups.com/forums/showthread.php?t=849691

http://www.rcgroups.com/forums/showthread.php?t=849374

http://www.runryder.com/helicopter/t426529p1

Near the end of this thread

http://www.archeli.com.au/cobra/showthread.php?t=115525

Cfranks also makes a post. He was one of those involved in getting the MAAA in Australia to approve the product, which eventually ended up biting him in the ass.


For those that haven’t seen this yet

http://www.rcgroups.com/forums/show...619&postcount=4

Note the date 1 April 2008. April’s fools day. Is this some kind of a hint?


Well JD did mention telemetry back in

http://www.rcuniverse.com/forum/m_47...tm.htm#4714231

June 2006 on this forum and a price of $129.

There is also mention of a firmware change, which was mentioned

http://www.rcgroups.com/forums/showt...ghlight=Toledo

So why has the new firmware not been released? JD promised it would be available at the Toledo show so what happened?


As for the 900Mhz modules

http://www.rcgroups.com/forums/showp...71&postcount=7

The Xbeepro module data sheet including the 900Mhz.

http://www.digi.com/pdf/ds_xbeemultipointmodules.pdf

http://www.rcgroups.com/forums/showthread.php?t=816989

I made a post in there got me temporarily banned from Rcgroups and NO it wasn’t because I was attacking XPS. Explanation is given here

http://www.archeli.com.au/cobra/showthread.php?t=115696

[gareth.ky]

Isotropic Radiator's do not exist. NASA has tried to construct them with genetic algorithms and still not gotten there. They are a purely theoretical construct. A fantasy. No such antenna exists.

The Di-Pole antenna used in ever commercial WiFi and R/C device comes very close! For all practical applications a dipole is sufficient, even R/C. That is the configuration every system on the market uses.

when a company claims to have a spherical (Isotropic) radiator in the same form factor as the well understood Di-Pole antenna you should take that will a pound of salt. It sounds good and for all practical purposes they are correct. For absolute scientific purposes they are full of $#!t.

Spend your $$$$ accordingly.

[XJet]

	Quote: Originally Posted by Reckless Loony
	Here is something people might find interesting. http://www.automags.org/forums/showthread.php?t=116538 The interview link is dead

You've got to love the Web Archive:

Archived copy of interview

[KrisW]

	Quote: Originally Posted by JimDrew
	The reality is that we don't fly models on a bench, and certainly not within inches of a WiFi device hooked to a computer. The power output required to cause what is demonstrated here while flying would cause the saturation of the entire 2.4GHz band (above and below 2.4GHz), and not a single frequency. A good example of this is the flying field in Davis, CA. The Nexrad that sits just a few miles away from the field transmits on 2.7GHz, yet 750,000 watts appears to bleed over so badly that none of the 2.4GHz systems will work. They won't even connect if they are within a mile of the tower. Hopping when there is nowhere to go is a bit foolish, and that the reality of the environment that we use our radio systems in.

Jim, way back in my Youth I worked as an IMA level Avionic tech in the Marines. I got my AS degree and a plethora of side training into all sorts of neato cutting edge technology back then. It's a little outdated by todays standards, but one thing held true then, that is vey applicable TODAY. A piece of gear came in from a squadron, and we threw it onto a TEST BENCH. We trouble shot it, found the bad components, repaired it ourselves, then realigned the gear to specs according to the HSI, CDI'd it off a rigorous testing (sometimes HOURS on a test bench for the final testing) and then packaged it up and sent it back to the squadrons or Supply for future use. I even got 4 "Technical upgrade design" bonuses for improving some of the older gear to alleviate recurrent problems with certain components/modules. . you see, I liked to tinker, and not having a life I played around (at tax payers expense) and redesigned a few things to make them better and shave maintenance and support time off our overloaded work sections at the IMA level.

But, when Pilots and aircrews LIVES depended on our performance, we were pretty hard core and dedicated to perfection in our work. Many in the IMA worked 12 hour shifts, 7 days a week, for months on end, keeping our birds in the air. I did this for 10 years straight, and the one thing that ALWAYS rang true is. . .if it works on the bench, it will work in the air. . PERIOD.

So. . a piece of advice . . STOP with this lie about how you perform "real world" testing, and that bench testing is somehow different from your "Real World" setup. NO ONE believes you. . any technician in the Electronics market will laugh himself silly at what you are saying, and a lot of people who are a lot better at this stuff than you are will just shake their heads at such a blatant falsehood and walk away.



Now, concerning your magical "spherical radiation" . . Receivers do not radiate, first off (yet your receiver uses the same shape antenna as your TX) and it is physically impossible to have a single stick antenna, no matter how it is wound with wire, that can achieve a 100% spherical reception or transmissioin pattern. The areas along the axis of the antenna will ALWAYS have a Null, or degraded receptivity/transmission area. I pointed this out when you put up the pics well over a year ago, and told people to make sure they did not point either the TX, or RX antennae directly at eachother, due to the nulls along the antenna's axis, and that signal loss would probably occur.

You still, to this day, do not have satellite antenna assemblies, which would go a long way to improving your product. I don't know if it's just stubborn, foolish pride, or lack of R&D capital that keeps you from bringing this into being, but your assertions about not needing such items are very ignorant of how "Real World" radio gear actually works.

I actually supported you, Jim Drew, way back in the beginning, because I thought you were actually bringing out a viable product that would do all the things you claimed it would. The more YOU talked, and the more the "Real World" refuted what you were saying, the more I examined your equipment. I didn't take long to figure out just how full of it you really were. I certainly will never buy anything you are associated with.

As for sideband bleed over from 2.7 ghz. . I'm not buying it. Anything making a trip THAT far (300 megahertz) is severely degraded to the point of being a non factor. . OR so powerful (and they are pumping a TON of power to do it) it would blank the entire 2.4g band, and render everything on that band inoperable. C'mon Jim. .you are a drowning man grasping at straw. . please stop it. . it's embarassing to watch.

Someday I expect to see you on TV doing infomercials and taking the place of Billy Mays selling all those silly products that people buy. You are so good at it. . it seems like a natural niche for you in the future. But, please, a little honesty and humility would help a lot right now. No one is listening to you, and I seriously dout that any of us care for any more excuses.

Here's what WE want to hear"
XPS is a single channel, non agile 2.4 ghz system (that's the truth)
XPS uses the best dipole antennas available, but the end user needs to be aware of the possibility of Nulls in the pattern, and make sure the nulls never coincide (again, the truth)
XPS can be shadowed by large components or CF parts (the truth)
In certain circumstances XPS MIGHT change channels, but it is not guaranteed and the end user should not depend on this to save his aircraft if interference occurs (again . .this is the truth)

More "True statements", if applicable. . most are questionable at this juncture

We are working to improve the design.
We are working on upgraded firmware to improve any frequency agility.
We are working on satellite receiver options
We have designs in place, but no actual product, for telemetry, at this time. It will be released as it is finished in testing and approved for airborn use.

And LASTLY .. the End User is the most important asset we have. We are totally dedicated to his confidence in our product. (this one still needs a LOT of work)

[klhoard]

	Quote: Originally Posted by KrisW
	. . .<snip>. . Here's what WE want to hear". . .<snip>. .

.
.
"Due to a severe shortage of Cow Dung in the Lake Havasu area, we must announce that we are shutting down our BS Factory and I am going back to Paintball". . .
.
.