True. The ping frequency is low though (hundreds of ms between pings) which limits the modulation sidelobes, and even the initial banging on of the carrier at the beginning of each ping is fairly well bandpass filtered by the high Q of the transmitter. You can't hear a tag click/chirp/whatever if you hold it against your ear.
But if seals can detect upwards of 180khz as you're saying... Yeah, that's a problem.
Going higher than 69KHz reduces the range of the tags, as higher frequencies are attenuated more in water. This means you'll need a more powerful tag (with size/battery life implications) or more deployed receivers to make the system work at a higher frequency.
The tags do produce harmonics at 138KHz/207KHz/onwards, but there's no distortion mechanism present that should allow frequencies lower than 69KHz to be created. There's no modulation done on the 69KHz carrier, the carrier is on/off keyed with time differences from one ping to the next being used to encode the tag's unique ID.
Radio waves don't travel well underwater. You need stupidly low frequencies like those used for submarine communication, and you won't be able to generate those frequencies from an object that's a few cm long which means you're stuck with acoustic methods. The tags in question operate at 69KHz, which as far as I know is outside the hearing range of seals - this article makes me wonder though, I've got it bookmarked and I'll give the underlying paper a good read when I've got the time.
I'm actually an engineer at the company that makes the tags in question. We're hardly a huge corporation (100 people) and we don't have the financial clout or even any obvious reason to bankroll corrupt science - we just make scientific gear that helps scientists do their science. I wouldn't consider us to be much different from a company that makes lab coats or glassware.
I've done this - I had a Toyota Cressida chair in my house, with a SLA battery and trickle charger hooked up to run the power seat bits.
However, I'll warn that it's hard to construct such a thing without making it look ghetto. Eventually, spousal acceptance factor led to the demise of the chair.
Funny. Yesterday we had a couple of modules come in for our MDO3K series scopes, and a co-worker and I were hypothesizing about what's in the modules. We concluded they were probably using smartcard IC's, because after all you're selling these things to engineers - people who would be smart enough to break the system if you did something cheap like a TWI EEPROM.
Ha!
Thanks to this DMCA takedown, and the attention it brought, we'll be breaking out the Bus Pirate. You won't need a smartcard connector or custom PCB - a half dozen pogo pins on protoboard will do the job just fine.
Given selected music with characteristics that make a MP3 encoder generate artifacts, a good playback system, a set of headphones with good treble reproduction, and a quiet environment, I can consistently point out the difference between the uncompressed music and a 256kbps CBR MP3 made from it by carefully listening for specific artifacts.
With the majority of music in the majority of listening environments, well-encoded lossy audio content isn't noticeable. But on rare occasions it is - and I don't believe accepting that fact makes me a green-marker-in-hand audiophile.
- Requires extra machinery/infrastructure to be installed at the HD plant - Expense of buying helium - Expense of other drive changes required to support helium (better sealing, etc) - Expense of licensing existing patents on helium filled drives and their manufacture.
Or perhaps they're just busy validating new drive models and their assembly line, and they'll be shipping helium filled drives shortly...
Lately I've been playing a bunch of old games, using new source ports/engines, eg:
- Duke Nukem 3D (using eduke3d engine + high resolution pack) - Descent series (using DXX-Rebirth engine) - Doom/Doom2 (using zdoom + high res texture pack)
I've got a never-ending fondness for these old games, and the new engines allow for an enjoyable gameplay experience - 320x200 on a 14" CRT back in the day was acceptable, not so much on a modern LCD. I can't give enough thanks to the people who run these projects.
My VW specialist mechanic buys older VWs, overhauls them, puts in modern engines and sells them for a nice profit. Eurovans/Wesfalias primarily, also MK1 Rabbits, MK2 golfs/jettas, caddies, etc. He can't keep up with demand.
Though, I do believe VW enthusiasts are more likely to go for such a thing - I can't see someone spending several $K getting their pontiac sunfire rebuilt.
Don't buy your CFLs from a retail store. Find a local industrial supplier (eg, Grainger) that sells GE or Osram/Sylvania professional bulbs and go with them. Pick some part #s off the manufacturer websites to have ready when you walk in.
My house is full of GE FLE10HT2/2/827 CFLs, 40W equivalents that pull 10W. 2700K color temperature so their light output is easy on the eyes, and they've got a rated 12000 hour lifetime that I believe - I bought this house 6 years ago and bought a case of these bulbs to replace the existing incandescent bulbs, most of those bulbs are still in place. Indoors, they start up with about 1/4 second of lag and don't have any noticeable warmup period.
I swear by 'em. When LEDs come down to the same price I'll switch over, but I'll stick with CFLs for the time being.
- SSH to serial converter. Plug a couple of USB-RS232 cables into the Pi, plug them into serial consoles on servers/industrial equipment/whatever, and you no longer have to crouch behind a rack with a laptop whenever you need to monitor/control stuff. - Print server for a USB laser printer - NAS/backup machine/torrent downloader/etc - New guts for a broken NES.
I'm sure the closed-source GPU and ARM11 CPU offend some people, but hey, it gets the job done in places I've stuffed it.
The Cyclone II on that card is several years old, a modern equivalent of the FPGA is about $12. Now if you haul the x86 and everything else out, you've got plenty of room freed up to enhance up that VGA controller into something more modern. That's what they're going for here.
If AMD put HDMI ports on their video card, they'd have to pay licensing/royalty fees to HDMI Licensing, LLC. By only putting DVI connectors on their video cards, ATI doesn't have to pay the fee. But for the small percentage of customers who *want* HDMI, they sell the adapter and pay for the licensing costs with that instead. Since they sell far fewer adapters than cards obviously, the overall license fees paid become much less.
Presumably the EEPROM is in there because the HDMI Licensing lawyers aren't complete idiots, and required the card to make sure the adapter is licensed. Tossing a 10-cent 24LC01 or something in there with a magic byte on it probably didn't break the bank.
Re:Thanks, from an embedded designer.
on
Debian Turns 20
·
· Score: 1
In one case I selected an ARM chip, drew the schematic, made a set of rules for the PCB guy so the DRAM/flash interface would have good signal integrity, verified the layout and had it sent off for manufacture. Then brought the prototype board up, broke out the J-Link, verified the hardware, banged out and debugged an assembly code bootloader to initialize the ARM and pull the customized kernel out of NAND. Once I had Debian running stable on there, I handed it off to the software guys for them to do their part.
But sigh, it runs an OS, so I guess I'm not an embedded designer. Got a better job title?
Thanks, from an embedded designer.
on
Debian Turns 20
·
· Score: 2
I've used Debian extensively in the past for embedded Linux development - I've got equipment in the field running on the x86, armel, mips and powerpc ports, from biscuit PCs running full GUIs to $10 uP's doing network-attached-widget duties in the corner of a PCB.
Debian's "non-x86" ports work well, the distribution is simple, trims down small, easily modified for whatever purpose, and it just plain gets the job done. Couldn't be happier with it.
... can we stop using that word? I don't know if it's the same for anyone else, but whenever I hear that word it sounds like something between the word "synergy" and an ice pick stabbed into my ear.
Speaking as an outdoorsman that has come across far too many dead/wounded deer in the woods... If a hunter using this setup is much more likely to score a single fatal shot on game, killing it with as little suffering as possible, I hope this makes it to market as quick as possible.
Around here half the deer hunters don't bother going to the shooting range, and they're god-awful shots because of it. So they end up wounding whatever deer they shoot at, and the poor thing takes off and suffers for hours until it either bleeds to death or a coyote brings it down.
TFA mentions at least one challenge. Kit in automobiles have to be built for extreme conditions (temperature range, vibrations, chemicals, dust, etc).
Hyperbole. The engine management and other systems vital to operation of the car have to meet such specifications, but infotainment systems can be mounted in the passenger compartment side of the firewall and so don't need to withstand such environmental conditions.
Take a consumer hard drive, put it in a deep freeze and let it chill to -20C. Now take it out and plug it in your PC.
Is it gonna work? No? Well I guess the same hard drive won't work in a car that's been parked overnight in the winter.
And that's just the first test your hardware has to pass before it can be installed in a car. Next up, vibration testing...
Never put a PC/104 setup in a system that's going to be subjected to vibration, you'll cause the connector to wear out and eventually one of the important pins on the PC/104 connector will fail. And when it does, the ISA bus presented on the PC104 connector doesn't have any error detection/correction either, meaning your system may not fail gracefully.
- The music being encoded. Some songs have combinations of sounds which don't encode well. - The encoding format, and the type of artifacts that it produces. - The bitrate and other encoder configuration. - The playback gear being used, and the listening environment. A quiet environment and gear with clear treble reproduction will tend to highlight encoding artifacts. - The listener, and whether they know what to listen for.
I spent most of a decade designing broadcast audio hardware and DSP code, and as a result I've become pretty good at picking out glitches/artifacts/etc - especially with familiar songs. But I'm not most people.
I'm envisioning a little PCB that goes between a power cable and a SSD, and has some power management parts and a holdover capacitor. If power fails it would provide power to the SSD for a few seconds, hopefully long enough for it to flush its data to NAND. Could also do overvoltage protection etc. to prevent a bad power supply from frying the SSD as an extra feature. Should only cost ~$10-20 or so to make in quantities of 10 or so, and be a pretty quick design to bang out.
It won't fit in anything other than a desktop PC. And I wouldn't be surprised if some SSDs would still drop dead with the card, because they'd have some dumb quirk like the controller hanging up if the SATA interface drops dead...
- Buy another one of these drives and gut it. Replace or reprogram the touchscreen controller, and stuff a GSM modem in there. - Program the controller to act like an ordinary drive, but send the entered password as a text message via the GSM modem. Make it act like the password was entered wrong so the user enters it a few times. - Swap the modified "drive" for the users' original drive. - Wait for the password to arrive at your prepaid cellphone.
You can break Truecrypt the same way - copy a users' encrypted data, and replace the Truecrypt executable with one that broadcasts the password when the user types it.
Not sure what this attack is called - "false keypad attack"?
Definitely. 3rd harmonic of the broadcast carrier lands right on top of the 315MHz band.
3rd harmonic is very easy to generate - unless you've spent a *ton* of money on your FM exciter, made every amplifier stage seriously overbiased and underdriven, etc.. you'll have a significant amount of 3rd harmonic coming out of your final amplifier. And it's hard to get rid of, requiring a sharp lowpass or notch on the transmitter output.
And dipole antennas work perfectly fine at odd order harmonics.
I used to design AM/FM broadcast equipment for a living, and making the output of a FM transmitter pass spectrum requirements takes an enormous amount of design effort and testing. "Making a filter to take the harmonics out" is easy to say - but at VHF L's look like C's, C's look like L's and R is never exactly 0 or 50.
Slashdot Mirror
True. The ping frequency is low though (hundreds of ms between pings) which limits the modulation sidelobes, and even the initial banging on of the carrier at the beginning of each ping is fairly well bandpass filtered by the high Q of the transmitter. You can't hear a tag click/chirp/whatever if you hold it against your ear.
But if seals can detect upwards of 180khz as you're saying... Yeah, that's a problem.
Going higher than 69KHz reduces the range of the tags, as higher frequencies are attenuated more in water. This means you'll need a more powerful tag (with size/battery life implications) or more deployed receivers to make the system work at a higher frequency.
The tags do produce harmonics at 138KHz/207KHz/onwards, but there's no distortion mechanism present that should allow frequencies lower than 69KHz to be created. There's no modulation done on the 69KHz carrier, the carrier is on/off keyed with time differences from one ping to the next being used to encode the tag's unique ID.
Radio waves don't travel well underwater. You need stupidly low frequencies like those used for submarine communication, and you won't be able to generate those frequencies from an object that's a few cm long which means you're stuck with acoustic methods. The tags in question operate at 69KHz, which as far as I know is outside the hearing range of seals - this article makes me wonder though, I've got it bookmarked and I'll give the underlying paper a good read when I've got the time.
I'm actually an engineer at the company that makes the tags in question. We're hardly a huge corporation (100 people) and we don't have the financial clout or even any obvious reason to bankroll corrupt science - we just make scientific gear that helps scientists do their science. I wouldn't consider us to be much different from a company that makes lab coats or glassware.
If rob ford were the PM there would be swift response.
Like what, a crack-down?
I've done this - I had a Toyota Cressida chair in my house, with a SLA battery and trickle charger hooked up to run the power seat bits.
However, I'll warn that it's hard to construct such a thing without making it look ghetto. Eventually, spousal acceptance factor led to the demise of the chair.
Funny. Yesterday we had a couple of modules come in for our MDO3K series scopes, and a co-worker and I were hypothesizing about what's in the modules. We concluded they were probably using smartcard IC's, because after all you're selling these things to engineers - people who would be smart enough to break the system if you did something cheap like a TWI EEPROM.
Ha!
Thanks to this DMCA takedown, and the attention it brought, we'll be breaking out the Bus Pirate. You won't need a smartcard connector or custom PCB - a half dozen pogo pins on protoboard will do the job just fine.
... dementia is the highest level you can achieve of not giving a shit about anything anymore.
Given selected music with characteristics that make a MP3 encoder generate artifacts, a good playback system, a set of headphones with good treble reproduction, and a quiet environment, I can consistently point out the difference between the uncompressed music and a 256kbps CBR MP3 made from it by carefully listening for specific artifacts.
With the majority of music in the majority of listening environments, well-encoded lossy audio content isn't noticeable. But on rare occasions it is - and I don't believe accepting that fact makes me a green-marker-in-hand audiophile.
Why not?
- Requires extra machinery/infrastructure to be installed at the HD plant
- Expense of buying helium
- Expense of other drive changes required to support helium (better sealing, etc)
- Expense of licensing existing patents on helium filled drives and their manufacture.
Or perhaps they're just busy validating new drive models and their assembly line, and they'll be shipping helium filled drives shortly...
Lately I've been playing a bunch of old games, using new source ports/engines, eg:
- Duke Nukem 3D (using eduke3d engine + high resolution pack)
- Descent series (using DXX-Rebirth engine)
- Doom/Doom2 (using zdoom + high res texture pack)
I've got a never-ending fondness for these old games, and the new engines allow for an enjoyable gameplay experience - 320x200 on a 14" CRT back in the day was acceptable, not so much on a modern LCD. I can't give enough thanks to the people who run these projects.
My VW specialist mechanic buys older VWs, overhauls them, puts in modern engines and sells them for a nice profit. Eurovans/Wesfalias primarily, also MK1 Rabbits, MK2 golfs/jettas, caddies, etc. He can't keep up with demand.
Though, I do believe VW enthusiasts are more likely to go for such a thing - I can't see someone spending several $K getting their pontiac sunfire rebuilt.
Don't buy your CFLs from a retail store. Find a local industrial supplier (eg, Grainger) that sells GE or Osram/Sylvania professional bulbs and go with them. Pick some part #s off the manufacturer websites to have ready when you walk in.
My house is full of GE FLE10HT2/2/827 CFLs, 40W equivalents that pull 10W. 2700K color temperature so their light output is easy on the eyes, and they've got a rated 12000 hour lifetime that I believe - I bought this house 6 years ago and bought a case of these bulbs to replace the existing incandescent bulbs, most of those bulbs are still in place. Indoors, they start up with about 1/4 second of lag and don't have any noticeable warmup period.
I swear by 'em. When LEDs come down to the same price I'll switch over, but I'll stick with CFLs for the time being.
- SSH to serial converter. Plug a couple of USB-RS232 cables into the Pi, plug them into serial consoles on servers/industrial equipment/whatever, and you no longer have to crouch behind a rack with a laptop whenever you need to monitor/control stuff.
- Print server for a USB laser printer
- NAS/backup machine/torrent downloader/etc
- New guts for a broken NES.
I'm sure the closed-source GPU and ARM11 CPU offend some people, but hey, it gets the job done in places I've stuffed it.
Even the highest end Virtex can't touch one of AMD/nVidia's ASICs for 3D rendering, but that isn't the target market for this design.
Here's an evaluation board for a low end FPGA chip, emulating a full 80186 PC including CPU, BIOS, keyboard controller, and VGA video:
http://zet.aluzina.org/index.php/Altera_DE1_Installation_guide
The Cyclone II on that card is several years old, a modern equivalent of the FPGA is about $12. Now if you haul the x86 and everything else out, you've got plenty of room freed up to enhance up that VGA controller into something more modern. That's what they're going for here.
If AMD put HDMI ports on their video card, they'd have to pay licensing/royalty fees to HDMI Licensing, LLC. By only putting DVI connectors on their video cards, ATI doesn't have to pay the fee. But for the small percentage of customers who *want* HDMI, they sell the adapter and pay for the licensing costs with that instead. Since they sell far fewer adapters than cards obviously, the overall license fees paid become much less.
Presumably the EEPROM is in there because the HDMI Licensing lawyers aren't complete idiots, and required the card to make sure the adapter is licensed. Tossing a 10-cent 24LC01 or something in there with a magic byte on it probably didn't break the bank.
In one case I selected an ARM chip, drew the schematic, made a set of rules for the PCB guy so the DRAM/flash interface would have good signal integrity, verified the layout and had it sent off for manufacture. Then brought the prototype board up, broke out the J-Link, verified the hardware, banged out and debugged an assembly code bootloader to initialize the ARM and pull the customized kernel out of NAND. Once I had Debian running stable on there, I handed it off to the software guys for them to do their part.
But sigh, it runs an OS, so I guess I'm not an embedded designer. Got a better job title?
I've used Debian extensively in the past for embedded Linux development - I've got equipment in the field running on the x86, armel, mips and powerpc ports, from biscuit PCs running full GUIs to $10 uP's doing network-attached-widget duties in the corner of a PCB.
Debian's "non-x86" ports work well, the distribution is simple, trims down small, easily modified for whatever purpose, and it just plain gets the job done. Couldn't be happier with it.
... can we stop using that word? I don't know if it's the same for anyone else, but whenever I hear that word it sounds like something between the word "synergy" and an ice pick stabbed into my ear.
Speaking as an outdoorsman that has come across far too many dead/wounded deer in the woods... If a hunter using this setup is much more likely to score a single fatal shot on game, killing it with as little suffering as possible, I hope this makes it to market as quick as possible.
Around here half the deer hunters don't bother going to the shooting range, and they're god-awful shots because of it. So they end up wounding whatever deer they shoot at, and the poor thing takes off and suffers for hours until it either bleeds to death or a coyote brings it down.
Hyperbole. The engine management and other systems vital to operation of the car have to meet such specifications, but infotainment systems can be mounted in the passenger compartment side of the firewall and so don't need to withstand such environmental conditions.
Take a consumer hard drive, put it in a deep freeze and let it chill to -20C. Now take it out and plug it in your PC.
Is it gonna work? No? Well I guess the same hard drive won't work in a car that's been parked overnight in the winter.
And that's just the first test your hardware has to pass before it can be installed in a car. Next up, vibration testing...
From personal experience.
Never put a PC/104 setup in a system that's going to be subjected to vibration, you'll cause the connector to wear out and eventually one of the important pins on the PC/104 connector will fail. And when it does, the ISA bus presented on the PC104 connector doesn't have any error detection/correction either, meaning your system may not fail gracefully.
Not something you want in a large robot.
Lets see...
- The music being encoded. Some songs have combinations of sounds which don't encode well.
- The encoding format, and the type of artifacts that it produces.
- The bitrate and other encoder configuration.
- The playback gear being used, and the listening environment. A quiet environment and gear with clear treble reproduction will tend to highlight encoding artifacts.
- The listener, and whether they know what to listen for.
I spent most of a decade designing broadcast audio hardware and DSP code, and as a result I've become pretty good at picking out glitches/artifacts/etc - especially with familiar songs. But I'm not most people.
I'm envisioning a little PCB that goes between a power cable and a SSD, and has some power management parts and a holdover capacitor. If power fails it would provide power to the SSD for a few seconds, hopefully long enough for it to flush its data to NAND. Could also do overvoltage protection etc. to prevent a bad power supply from frying the SSD as an extra feature. Should only cost ~$10-20 or so to make in quantities of 10 or so, and be a pretty quick design to bang out.
It won't fit in anything other than a desktop PC. And I wouldn't be surprised if some SSDs would still drop dead with the card, because they'd have some dumb quirk like the controller hanging up if the SATA interface drops dead...
Here's how you crack this.
- Buy another one of these drives and gut it. Replace or reprogram the touchscreen controller, and stuff a GSM modem in there.
- Program the controller to act like an ordinary drive, but send the entered password as a text message via the GSM modem. Make it act like the password was entered wrong so the user enters it a few times.
- Swap the modified "drive" for the users' original drive.
- Wait for the password to arrive at your prepaid cellphone.
You can break Truecrypt the same way - copy a users' encrypted data, and replace the Truecrypt executable with one that broadcasts the password when the user types it.
Not sure what this attack is called - "false keypad attack"?
Definitely. 3rd harmonic of the broadcast carrier lands right on top of the 315MHz band.
3rd harmonic is very easy to generate - unless you've spent a *ton* of money on your FM exciter, made every amplifier stage seriously overbiased and underdriven, etc.. you'll have a significant amount of 3rd harmonic coming out of your final amplifier. And it's hard to get rid of, requiring a sharp lowpass or notch on the transmitter output.
And dipole antennas work perfectly fine at odd order harmonics.
I used to design AM/FM broadcast equipment for a living, and making the output of a FM transmitter pass spectrum requirements takes an enormous amount of design effort and testing. "Making a filter to take the harmonics out" is easy to say - but at VHF L's look like C's, C's look like L's and R is never exactly 0 or 50.