Forgot your password?
No account? Register one!
July 9, 2007
Engineer, experimenter, FAE
Johns Hopkins, University of Maryland, Virginia Tech
News - Enginursday: Yeah, I foun… |
I met a gentleman that built turbine controls for model aircraft and drones that used a Microchip dsPIC30. Turbines are amazing, remember to keep the control loop very quick- things can go very badly very quickly, it would be a shame to see this destroyed by a momentary lean condition.
I am clearly quite envious that I missed this auction- may I ask what it runs for (the turbine sans generator)?
Product CAB-11515 |
about a year ago
Caps over the unused ends of this cable (or shielding) would make virtually unmeasurable changes. The power in the cable in USB is always the same- it isn’t affected by speed. Also, the data rate on the cable is not a factor of the serial port speed you’re running. To really measure the EMI, you don’t really use a scope (you won’t see much at all)- you ought to use a spectrum analyzer.
Yes, each packet has CRC, but in my experience, most drivers deal with CRC failure horribly. USB just isn’t designed to run over a lossy medium. There is no “automatic” downshifting to lower speeds if the connection is poor. It is a statistics game, as long as the vast majority of the packets are good, USB works great, but the overall bit error rate that USB is designed for is something like a single bit error in minutes of operation.
Diagnosing USB cable problems is miserable- I had a bunch of USB 1.x cables that I ended up just cutting up and recycling because they kept getting into the mix and I’d spend a couple hours diagnosing what I thought was a USB driver problem, but turned out to be a non USB 2.0 cable. (It would connect and enumerate, but eventually fail, and the Windows error messages are particularly un-helpful.)
The issue is not if the situation is ideal or not, it’s a matter of what kind of issues you may be buying yourself into. I’m sure it will work to move data most of the time, but Murphy’s law is even more reliable than Godwin’s law.
When space is at a premium, this cable is awesome, and I really see how useful it could be, but USB cables are cheap and pretty small. This very well could find its way into my travel bag (for charging), but I will make it a point that a cable of this type should never be in my lab, except hooked up to a network analyzer as a demonstration of transmission line stub filters.
Depending on you you talk to, I could be an expert (or not :). Yes, it might fail CRC, but in my experience USB cable issues are absolutely a pain to identify- USB just isn’t designed to run over a lossy medium- I’ll think I’ll post a reply a little higher in the thread so people don’t miss this.
I’m not trying to be a whiner or mean- but you really need to read up more on USB. The speed on USB isn’t really variable- it runs at the maximum speed it is capable of at all time: USB low speed is 1.2Mbit/s (not much really uses this- keyboards and mice, maybe), USB full speed (12Mbit/s) and High speed (480 Mbit/s) (and ignoring USB 3). The rate that the individual packets move is always one of the above speeds. If you’re running a serial port at 110 baud over a converter that is connected at USB High speed- the data on the USB cable is running at 480 Mbit/s ALWAYS- there is just a lot of dead time.
The issue with signal integrity is that this kind of thing isn’t a problem, until it is catastrophic. The data failure may not happen frequently, it could happen randomly (errors in data are inevitable- they will happen), and the OS may hide them- but it could also be data pattern dependent, as a transmission line stub can look like a very narrow filter, and for certain data patterns (difficult to predict and likely to be different cable-cable), it could fail every time.
This is a great cable to have around for charging purposes or emergencies, but for every day use, USB cables are way too cheap to run the risk (for me).
The signal integrity guy in me shudders at this- while it may be awesome for supplying power, you’re breaking the transmission lines by adding some relatively significant stubs, and will very likely result in data corruption/loss.
Product WRL-09411 |
about a year ago
BitStream, you need to look up the concept of ‘antenna duality.’ Not counting nonlinearities (such as de-sensing of a pre-amp or arcing due to overload), the mathematical properties of an antenna as a transmitter are exactly the same as a receiver.
I have seen no-one mention the concept of the Fresnel-zone- doing RF at a small distance above a ground plane (like the earth) can cause destructive interference, seriously limiting range.
Product GPS-11115 |
about 2 years ago
FYI- the dsPIC33 on this has a maximum internal oscillator speed of 80 MHz, which is misleading anyway (clock rate != CPU speed), since it is divided by 2 to get the actual processor instruction clock, this part is really 40 MIPS.
The dsPIC30 used a 120MHz maximum clock, divided by 4 to get a 30 MIPS CPU.
Product SEN-09694 |
about 2 years ago
I’m running into some issues with my code and I hope someone could help. If I hard code the readings and calibration data that is shown on P.13 of the datasheet, I get the results shown in the datasheet, however, when I pull the real data and the real calibration off of the device, the pressure is way low (about 3.55psi, 24,500 Pa). The temperature readings are accurate, and when I change the oversampling, the results I get for pressure are consistent (about the same + expected noise) for oversampling of 0, 1, 2 and 3. I did have to play around with typecasting a bit to get things to match up with the reference code. I’d like to experiment with some other calibration data and readings to validate my calculations- at the moment, I have:
Oversampling (for this example) is 2
UT reads as 35405, which calculates to 21.5C
UP reads as 171740 (after the shift for oversampling), which results in a pressure of 24957, or 3.619psi. (way too low for my altitude, about 800ft ASL)
I’d appreciate if someone could either run my calibration an readings into their code and see if they get the same, or send me your calibration and readings I could run through my code.
FYI: this is being done in C on a PIC32 on a Digilent Uno32. I do plan to share the code once it works. I’ve got a bunch of things running on the same I2C bus under a scheduler I wrote- each sensor can have a different interval and it can do other operations on a different device while the I2C while the pressure sensor is waiting the requisite time.
No public wish lists :(