U.S EFF: Right-to-Repair Law Proposed ... for Cars
andyg (geekscape)
As more things include computers and become network connected, it
sounds like the start of a golden age for hacking. Until you combine
"restrictive practices by manufacturers" and the DCMA. And, it's
illegal to reverse-engineer those products that have "technological
protection measures" (at least in the U.S). Bad news for innovators :
(
Right-to-Repair Law Proposed
http://www.eff.org/deeplinks/2009/05/right-repair-law-pro
Australia did have reasonable laws regarding reverse-engineering.
But, since the introduction of the FTA (sneaking in DCMA as well) ...
I've not kept up with the current state of Australian law in this
regard.
Since user innovation is a crucial activity ... we need to ensure that
our legitimate activities aren't curtailed by unreasonable and
unscrupulous commercial manipulation / interpretation of the law.
hol...@netspace.net.au
A brief outline of my plans for the weekend in case you share similar interests.
The primary aim is to get an accelerometer talking to an Arduino within the
context of the Aiko framework.
Specifically an LTC1298 12 bit SPI A/D converter capturing the output from an
ADXL50 accelerometer and storing the 12 bit readings in a ring buffer in an
ATMEL AR45DB161B Dataflash ROM (which also interfaces via SPI) - there is some
code in the playground http://www.arduino.cc/playground/Code/Dataflash for this
memory - everyone seems to be rolling their own SPI code as there appears to be
no standard Arduino library for SPI - a shame because the ATMEGA8 et.al. has
hardware SPI.
When this is working on a breadboard I'll make up a small flight computer board
and do some flight testing. Since the LTC1298 is a 2 channel A/D the other
channel could read air pressure (and hence altitude) from one of the MPX4115A
pressure sensors that I've had sitting around since 2001 waiting for some decent
software that can run on a low-cost microprocessor that I can afford to lose in
a rocket.
Additional miscellaneous I2C peripherals that I currently have working (but
outside the framework) include a temp sensor and realtime clock. I have some
funky 0.4mm fibreglass PC board that I'm looking forward to trying out once
I etched my first proper double-sided PCB last night (on 1.6mm board) and it
feels like 3 to 4 times as much work as single sided board.
I have also bought a bunch of the DR3100 Virtualwire compatible transceivers
from RFM http://cypress.rfm.com/products/spec_sheet.php?record=DR3100 and might
have a play with those as well - they are similar in concept to the separate
transmit and receive modules from Jaycar that Jon has being experimenting with
(and work with the same library discussed below) although they suggest the
possibility of two-way telemetry - such as an airborne network instantiated
between multiple vehicles simultaneously - real cloud computing. Australian
based Mike McCauley has written a Virtual Wire Arduino library for these radios
that is really well documented here (beware PDF)
http://www.open.com.au/mikem/arduino/VirtualWire.pdf
Mike
------------------------------------------------------------
This email was sent from Netspace Webmail: http://www.netspace.net.au
Jonathan Oxer
> I have also bought a bunch of the DR3100 Virtualwire compatible transceivers
> from RFM http://cypress.rfm.com/products/spec_sheet.php?record=DR3100
Yes, those look really interesting and the lure of bidirectional comms
is very strong! The only reason I went for the other modules was that I
could get them quickly and cheaply at the local Jaycar.
Where did you get the DR3100s, and how much were they?
> Mike McCauley has written a Virtual Wire Arduino library for these radios
> that is really well documented here (beware PDF)
> http://www.open.com.au/mikem/arduino/VirtualWire.pdf
I'm impressed by that library. It worked very well right out of the box
with the Jaycar modules.
Cheers :-)
--
Jonathan Oxer
Ph +61 4 3851 6600
Geek My Ride! <http://www.geekmyride.org/>
Michael Borthwick
On 21/05/2009, at 5:13 PM, Jonathan Oxer wrote:
>
> On Thu, 2009-05-21 at 17:26 +1000, hol...@netspace.net.au wrote:
>
>> I have also bought a bunch of the DR3100 Virtualwire compatible
>> transceivers
>> from RFM http://cypress.rfm.com/products/spec_sheet.php?record=DR3100
>
> Yes, those look really interesting and the lure of bidirectional comms
> is very strong! The only reason I went for the other modules was
> that I
> could get them quickly and cheaply at the local Jaycar.
>
> Where did you get the DR3100s, and how much were they?
I picked them up from Rockby www.rockby.com.au (stock number 36392)
they are $26 individually but like all of their products there are
good discounts available if a bulk buy were organised. I bought a few
if people want to try them out first without hiking out to Clayton.
Examples of some other Rockby parts that are germane:
* The Dataflash chips I mentioned in the previous email AT45DB161B at
50c each (stock number 36863) CASON package. (Sparkfun sells the D
version for USD2.95 albeit in a slightly more friendly package) - I
bought 10 if anyone wants to play. The onboard Flash or EEPROM might
be large enough for some seconds of model rocket flight though ...
* HEF4094BT @ 20c each In QTY 10 (stock number 34707) - a surface
mount 8-stage shift-and-store bus register that can be used to connect
an LCD using only 3 I/0 lines on the Arduino (instead of at least 7)
by using the technique incorporated by Andy in the Aiko framework http://github.com/geekscape/arduino-framework/tree/master
Also see Dick Smith part number Z5692 at .94c for a well-priced
through-hole functional equivalent.
Rockby don't have everything but what they do have is well-priced.
They have interesting weekly specials and a surplus warehouse which
can be fun to rummage around.
I'd be happy to design a little daughter board using this shift
register if a few people were interested in de-cluttering their
breadboards without going to the slightly more expensive option of a
serial LCD such as Peter Anderson's K107 ie. http://moderndevice.com/LCD.shtml
, Sparkfun's SerLCD, Scott Edwards backpacks http://www.seetron.com/slcds.htm
or the many displays aimed at the case modding community.
Mike
andyg (geekscape)
On May 21, 5:26 pm, hol...@netspace.net.au wrote:
> A brief outline of my plans for the weekend in case you share similar interests.
> The primary aim is to get an accelerometer talking to an Arduino within the
> context of the Aiko framework.
improvements to Aiko, based on people's experience with using it.
More specifically, a Rocketry session is planned for Sunday 1 pm (with
at least ... JonO, PeteY, yourself ? and myself ... and anyone else
interested).
> everyone seems to be rolling their own SPI code as there appears to be
> no standard Arduino library for SPI - a shame because the ATMEGA8 et.al. has
> hardware SPI.
hardware hasn't been much good, so far.
Jon and I were thinking of just talking directly to an SD-card,
raw ... no file-system !
Let's create a hardware based SPI library.
> Additional miscellaneous I2C peripherals that I currently have working (but
> outside the framework) include a temp sensor and realtime clock.
http://www.sparkfun.com/commerce/product_info.php?products_id=99
> based Mike McCauley has written a Virtual Wire Arduino library for these radios
I'm in the process of using VirtualWire with other devices that don't
play-well-with-others, due to delay loops used for timing, e.g.
OneWire.
> Where did you get the DR3100s, and how much were they?
like to incorporate the DR3100 into Aiko.
So, yes, I'm happy to buy a spare pair of DR3100s, plus a couple of
Dataflash AT45DB161B. Thanks !
> I'd be happy to design a little daughter board using this shift
> register if a few people were interested in de-cluttering their
> breadboards
be excellent.
I'd guess that PeteY would also be in the market for such a thing.
Thanks Mike !
Joshua Bassett
I finally got myself into gear and I'll be coming to the meeting on
Saturday :)
Just piping in on the conversation: I've got some code that I wrote
for the ATmega128 to read/write to a MMC/SD card using hardware SPI.
It works well and I have also implemented a FAT32 filesystem layer on
top of it, although there wouldn't be enough space for the FAT32 code
on an standard Arduino. Happy to share what I've got with you as I
recall there was quite a few subtleties in getting the card to behave
properly.
Looking forward to meeting with you all.
Cheers,
Josh
@nullobject
Michael Borthwick
On 22/05/2009, at 8:22 AM, andyg (geekscape) wrote:
>
I'm currently running this code http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1206784528
which happened to work out-of-the-box with the LTC1298 AD however it
is not using the hardware SPI (even though it is using the same pins
as the hardware SPI!).
This is a really nicely documented example of how to R/W to an SPI
EEPROM http://www.arduino.cc/en/Tutorial/SPIEEPROM and it uses the
hardware SPI functionality which presumably means it can read faster
with less instruction clock cycles than the "bit banging" approach.
>
>
>> Additional miscellaneous I2C peripherals that I currently have
>> working (but
>> outside the framework) include a temp sensor and realtime clock.
>
> We do need real-time clock for Aiko. I've got one of these ...
> http://www.sparkfun.com/commerce/product_info.php?products_id=99
Yes the DS1307 is the popular of the Dallas RTC parts amongst
hobbiests - I had one running at your place the other day. Futurlec do
a nice board for less than half the cost of Sparkfun http://www.futurlec.com/Mini_DS1307.shtml
and Microzed - a supplier who have not emerged in the discussion so
far sell that bare part for $5.00 including the 32.768KHz "watch"
crystal http://www.microzed.com.au/chips.html (Jaycar only sell a
38KHz crystal - how time flies!).
However Dallas have much more interesting RTC chips than the DS1307
offering for example: built in temperature control of an internal
crystal; alarms and Ferroelectric RAM for not much more money and i
would get one of those if I was starting from scratch.
Luke Weston
Could somebody do me a huge favor, please?
I was just wondering if it might be possible for somebody who is
heading over to the meeting tomorrow to meet me at Camberwell station
on your way and give me a lift, since I don't have a car.
Thanks in advance,
Luke
andyg (geekscape)
On May 23, 2:29 am, Luke Weston <reindeerfloti...@gmail.com> wrote:
> I was just wondering if it might be possible for somebody who is
> heading over to the meeting tomorrow to meet me at Camberwell station
> on your way and give me a lift, since I don't have a car.
station and we'll organize something.
andyg (geekscape)
On May 22, 9:37 am, Joshua Bassett <josh.bass...@gmail.com> wrote:
> Just piping in on the conversation: I've got some code that I wrote
> for the ATmega128 to read/write to a MMC/SD card using hardware SPI.
> It works well and I have also implemented a FAT32 filesystem layer on
> top of it, although there wouldn't be enough space for the FAT32 code
> on an standard Arduino. Happy to share what I've got with you as I
> recall there was quite a few subtleties in getting the card to behave
> properly.
Having it in two layers (raw and FAT32) means that people can choose
based on their needs, e.g. small memory Arduino versus larger memory
(newer) Arduino.
For the rocket telemetry, there is no particular need for a FAT32 file-
system. Speed and memory constraints are more critical.
Sounds like the 3 of us, MikeB, yourself and myself (and anyone else
interested) should get our heads together on this, during this weekend.
Luke Weston
> I'd be happy to design a little daughter board using this shift
> register if a few people were interested in de-cluttering their
> breadboards without going to the slightly more expensive option of a
> , Sparkfun's SerLCD, Scott Edwards backpackshttp://www.seetron.com/slcds.htm
>
> Mike
on the weekend. You could either plug it in below the LCD with a right-
angle header strip,
or put the header on the back of the daughterboard and flip it over
and put it behind the LCD, like one of Scott Edwards "backpack"
boards.
http://minerva.splcrew.net/3WireLCD.brd
http://minerva.splcrew.net/3WireLCD.sch
What do you all think? Feel free to take it and use it as you wish if
you want; perhaps at some future time at a hackerspace meetup we might
fab a panel full of boards, since they're just small, simple single-
sided boards, and it might be nice to show PCB fabrication to any
people who might not have done it before.
[These are EAGLE files; can be opened with the free-as-in-beer version
of EAGLE. I know, open source fans might not like the EAGLE files; but
unfortunately I haven't learned how to use gEDA.]
Luke
Dohzer
but I'd definitely be interested in some single or double sided UV
etching if anyone has some experience.
It would still be cool to check out how other people go about chemical
etching.
On May 25, 1:52 am, Luke Weston <reindeerfloti...@gmail.com> wrote:
> > I'd be happy to design a little daughter board using this shift
> > register if a few people were interested in de-cluttering their
> > breadboards without going to the slightly more expensive option of a
> > serial LCD such as Peter Anderson's K107 ie.http://moderndevice.com/LCD.shtml
> > , Sparkfun's SerLCD, Scott Edwards backpackshttp://www.seetron.com/slcds.htm
> > or the many displays aimed at the case modding community.
>
> > Mike
>
> Well, here is that quick attempt at a daughter board I was working on
> on the weekend. You could either plug it in below the LCD with a right-
> angle header strip,
> or put the header on the back of the daughterboard and flip it over
> and put it behind the LCD, like one of Scott Edwards "backpack"
> boards.
>
Michael Borthwick
CapnKernel
> I've done single sided chemical etching before with some "OK" results,
> but I'd definitely be interested in some single or double sided UV
> etching if anyone has some experience.
> It would still be cool to check out how other people go about chemical
> etching.
My secret ingredient is the shiny backing sheet from laser printer
labels.
1. I print the board layout (mirror image) with a laser printer on a
piece of A4 paper to find out where on the paper it'll be.
2. Then over that printout, I tape a piece of shiny laser label
backing sheet.
3. I run that A4 page (plus attached shiny paper) through the laser
printer again.
This transfers the image as toner onto the shiny paper. Don't scratch
it, as it's quite fragile.
4. Next, I cut a piece of blank PCB (a little oversize).
5. I clean it with steel wool, then scrub it with paper and metho
until it won't leave a dark mark on the paper.
6. I tape the board to the printout, copper-to-shiny-side.
7. Then I get my clothes iron, and iron the paper. Because the label
backing sheet is shiny, the laser toner prefers to stick to the
copper.
8. After the board has cooled, I carefully peel back the backing sheet
(no soaking necessary like other methods).
I etch my boards in a solution of ammonium persulphate and hot water.
The solution needs to be kept hot (>75C) so I have another trick.
9. I get a small foam esky (6 can size), and fill it with boiling
water. This will stay hot for a long time, especially when and if the
lid is on.
10. I get a small zip-lock bag and put the circuit board and the
ammonium persulphate plus a little hot water into the zip-lock back.
11. Then I toss the whole bag into the esky and put the lid on.
12. Every minute, take the lid off, agitate the bag and check the
board, then put the lid back on.
Because I use a zip-lock bag, I only need enough ammonium persulphate
to make solution for inside the bag. Thermal mass is provided by the
rest of the water in the esky, and can be topped up from the jug. My
trick means I use less chemicals, have to dispose of less chemicals,
and the etchant stays hotter for longer.
11. After all the visible copper is gone, remove the board from the
zip-lock bag, and wash it in water.
12. Scrub the toner off with steel wool.
13. Drill the holes using a tungsten carbide drill.
14. Repeat steps 1-3 for the component overlay.
15. Line up the overlay using the drilled holes, and repeat steps 6-8
but using the non-copper side.
16. Spray the copper side of the board with lacquer.
Mitch.
CapnKernel
little larger than is required, because lines right near the edge
don't iron on so well...)
Mitch.
Dohzer
> I've done more than my fair share of PCB making using positive acting
> pre-sensitised board and would be happy to host a session at my place
> in Richmond for those interested in giving it a bash
>
I actually work in Collingwood and travel home via Richmond station,
so if you're happy with it, maybe we could organise a time after work
one day for you to teach me. :)
On May 29, 7:53 pm, CapnKernel <capnker...@gmail.com> wrote:
> My secret ingredient is the shiny backing sheet from laser printer
> labels.
results.
Luke Weston
regards to the rocket instrumentation project, to try and help get
some more documentation together in a concrete way, I've taken what
we've discussed thus far with regards to the hardware in the system
and put together a schematic.
This is only preliminary, and it's based only on the discussions I've
had and the posts I've seen. It's entirely plausible that it is
completely different to what you might have in mind, I know, so feel
free to contribute your own feedback.
http://minerva.splcrew.net/RocketInstrumentation.png
i) Temperature sensor.
Here I've just assumed that we can use a DS18B20 to measure
temperature; pretty simple really, just one microcontroller pin, and a
4.7 k pull-up resistor. We could of course have multiple sensors
throughout the rocket and just bus them all together, and connect them
all back to the one connector on the main PCB. There are other sensors
we could use in theory, but the DS18B20 is common, convenient to use,
and there is heaps of experience and documentation with regards to
using it in the Arduino community.
ii) GPS.
Here I've just picked an EM406A from SparkFun for the sake of drawing
this schematic, although we could use any one of a number of others.
It's pretty easy to interface, requiring no external components, just
a two-wire serial interface to the microcontroller (without a spare
UART available, this serial communication needs to be bit-banged using
software, which isn't really a problem, I don't think, but then again
I'm not a programmer. Do we need to choose a microcontroller pin for
the serial input with a hardware interrupt, or something like that?)
iii) Light sensors.
Just two LDRs connected to two microcontroller ADC inputs, connected
with a couple of resistors as voltage dividers. Pretty simple, really.
The resistor values might need to be tweaked depending on the typical
resistances of the LDRs used, but they should be pretty flexible, and
100 k should be about right, since we really only want qualitative
information from them anyway.
iv) Real-time clock.
I've just assumed we're using a DS1307 here, and this is really just a
very simple schematic which is needed to support this device. There
are a couple of 10 k pull-up resistors on the I2C bus, and a LED
connected to the 1 Hz clock output, just as a bit of an indicator that
the system is powered up and alive.
v) Flash memory.
Mike mentioned the AT45DB61B, and that looks like the perfect device.
It has heaps of storage, it's fast, it's easy to interface, and it's
inexpensive. There's nothing not to like with this suggestion. This is
a 3.3 V device, however, but the datasheet says that the
communications signals are 5 V tolerant, so there shouldn't be any
trouble with interfacing it. 2 Mb ought to be enough for anything
(touch wood) but if it isn't, there's no reason why another chip
couldn't be added on the SPI bus.
vi) RF telemetry.
Here, just for the sake of drawing the schematic, I've assumed we
might be using an XBee device, although if you wanted to change the
design to use, say, one of the DR3100 devices there wouldn't be much
of a change, they're still 3 V devices, using bidirectional serial
comms back to the microcontroller, so there really isn't much
difference. The XBees have a couple of LEDs to indicate their status,
eg. that they've got a communication link to another device, so I've
just added these in, since a few blinkenlights don't hurt :)
Note that the XBee is a 3.3V device, so I've just divided the data
input from the microcontroller down with a 2:1 voltage divider, which
should be fine.
vii) Microcontroller
Here I've just assumed that a standard Arduino Duemilanove board is
used, although there's no reason why we couldn't put the
microcontroller and everything in one board in theory. I've especially
chosen the pins allocated for the I2C and SPI buses to correspond to
the AVR's pins for those hardware interfaces, although if the
interfaces were implemented in software, any other pins could be used,
really. Because it's all abstracted into the off-the-shelf Arduino
board, there's really nothing else to comment on in this module of the
design.
viii) Accelerometer and ADCs.
I've just assumed we're using an ADXL330, and the LTC1298s and MPX4115
as Mike mentioned, which is a cool idea.
I chose the ADXL330 pretty much arbitrarily, since it's the first one
I could find an Eagle library for, it seems pretty common, and
SparkFun stock it.
I've put a bit of low-pass RC filtering on the output from the
barometric sensor, using the component values just as given from
Freescale AN146.
I'm currently working out the maths to read out the altitude from the
output from the barometric sensor, which isn't that trivial.
ix) Power supply
Here I've got a MAX1555, which will charge a 3.7 V Li-Poly cell from a
USB connection... if one of the standard Arduino boards was used, or
if we put a USB connector and FTDI chip on the board, this USB input
could be connected to the USB 5 V rail, for example by connecting it
to the drain of the PFET on the Arduino Duemilanove board. That way,
when you plug in a USB cable to download telemetry data from the
Arduino, you're charging the battery.
There's also a MAX1703, which steps up the 3.7 V from the battery to
regulated 5V, and a LM1117-3.3, to regulate the 5V down to 3.3V. The
MAX1703 circuit is just standard datasheet material.
If we add up the power consumption for these devices, we're looking at
this:
ATMega168: 200 mA @ 5 V
EM406A: 44 mA @ 5 V
MPX415: 10 mA @ 5V
DS1307: 1.5 mA @ 5 V
LTC1298s: 350 uA * 2 @ 5V
Total: 257 mA @ 5 V
XBee Pro: 215 mA @ 3.3 V
AT45DB161B: 35 mA @ 3.3 V
ADXL330: 200 uA @ 3.3 V
Total: 250.2 mA @ 3.3 V
Here I've made conservative assumptions using the worst-case values,
eg. using the values for current draw during active write to the
DataFlash, active AD conversion at the highest possible sample
frequency, using the XBee Pro instead of the normal one, and so forth.
Anyway; this is all preliminary, I've made some somewhat arbitary
choices with regards to certain components just for the sake of
putting some ideas to paper, and more discussion would be great. Of
course, it's entirely possible that I've done something stupid with
the above schematic, and peer review with some other sets of eyes
would be useful. Anyway, I hope you find it useful.
Luke
Jonathan Oxer
> In order to try and document what we've been talking about with
> regards to the rocket instrumentation project, to try and help get
> some more documentation together in a concrete way, I've taken what
> we've discussed thus far with regards to the hardware in the system
> and put together a schematic.
Nice work Luke! Your modular approach is very sensible given that we may
want to interchange various chunks of functionality, and it allows the
various subsystems to be documented (and even built and tested)
individually much more easily than with a monolithic design. The
schematic is very clear and well thought out.
> ii) GPS.
> Here I've just picked an EM406A from SparkFun for the sake of drawing
> this schematic
The 406 has been around for a while, is well documented and supported,
and should be fairly easy to get going. However, it only provides 1Hz
updates and in a fast-moving rocket we probably want a bit more than
that. I got a Locosys LS20031 from Sparkfun which does 5Hz updates but
has the downside that it's a 3.3V device and so is a little harder to
interface to a Duemilanove. And at 5Hz...
> (without a spare
> UART available, this serial communication needs to be bit-banged using
> software, which isn't really a problem, I don't think, but then again
> I'm not a programmer. Do we need to choose a microcontroller pin for
> the serial input with a hardware interrupt, or something like that?)
... the serial comms has to be a lot faster than 4800bps to push that
volume of data through fast enough. In fact the suggested rate is
57600bps when running 5Hz updates and SoftwareSerial really has trouble
(read: won't work at all with the old timer code, barely works with the
new timer code) at that speed. The end result is that the GPS will
almost certainly need to be connected to a real UART rather than
bit-banged in software.
For reference, this is the GPS I have:
http://www.sparkfun.com/commerce/product_info.php?products_id=8975
I haven't actually got it working at all on an Arduino yet. I can talk
to it from a Windows machine connecting via a 3.3V FTDI cable, but my
initial testing with a Mega got pretty much nowhere and I haven't had a
chance to revisit it yet.
Shaun Moss
Dohzer
> i) Temperature sensor.
> Here I've just assumed that we can use a DS18B20 to measure
> temperature; pretty simple really, just one microcontroller pin, and a
> 4.7 k pull-up resistor. We could of course have multiple sensors
> throughout the rocket and just bus them all together, and connect them
> all back to the one connector on the main PCB. There are other sensors
> we could use in theory, but the DS18B20 is common, convenient to use,
> and there is heaps of experience and documentation with regards to
> using it in the Arduino community.
Those are the same 1-wire sensors you were using the other day, right?
What are they like to use? I've never done anything with 1-wire
before, so maybe I'll read up on the chip.
Where did you get them? Is there an Australian source or free samples?
andyg (geekscape)
> Those are the same 1-wire sensors you were using the other day, right?
> What are they like to use? I've never done anything with 1-wire
> before, so maybe I'll read up on the chip.
> Where did you get them? Is there an Australian source or free samples?
Luke Weston
>
> A brief outline of my plans for the weekend in case you share similar interests.
>
> The primary aim is to get an accelerometer talking to an Arduino within the
> context of the Aiko framework.
>
> Specifically an LTC1298 12 bit SPI A/D converter capturing the output from an
> ADXL50 accelerometer and storing the 12 bit readings in a ring buffer in an
> ATMEL AR45DB161B Dataflash ROM (which also interfaces via SPI) - there is some
> no standard Arduino library for SPI - a shame because the ATMEGA8 et.al. has
> hardware SPI.
>
> When this is working on a breadboard I'll make up a small flight computer board
> and do some flight testing. Since the LTC1298 is a 2 channel A/D the other
> channel could read air pressure (and hence altitude) from one of the MPX4115A
> pressure sensors that I've had sitting around since 2001 waiting for some decent
> software that can run on a low-cost microprocessor that I can afford to lose in
> a rocket.
>
> Additional miscellaneous I2C peripherals that I currently have working (but
> outside the framework) include a temp sensor and realtime clock. I have some
> funky 0.4mm fibreglass PC board that I'm looking forward to trying out once
>
> I etched my first proper double-sided PCB last night (on 1.6mm board) and it
> feels like 3 to 4 times as much work as single sided board.
>
> I have also bought a bunch of the DR3100 Virtualwire compatible transceivers
> transmit and receive modules from Jaycar that Jon has being experimenting with
> (and work with the same library discussed below) although they suggest the
> possibility of two-way telemetry - such as an airborne network instantiated
> between multiple vehicles simultaneously - real cloud computing. Australian
> based Mike McCauley has written a Virtual Wire Arduino library for these radios
> Mike
>
> ------------------------------------------------------------
> This email was sent from Netspace Webmail:http://www.netspace.net.au
You mentioned you're working with some LTC1298 ADCs... where did you
source those from? They don't seem too easy to track down a supplier
for.
Cheers,
Luke
Shaun Moss
else) at Miniatur Wunderland, the world's largest model railway, in
Hamburg. Every car in the model is controlled by a single process on
the control computer, and makes 20 decisions per second, including
testing for weak battery, when to change lanes etc.
http://www.miniatur-wunderland.com/exhibit/technology/carsystem/technology/
Shaun
Jonathan Oxer
I just randomly came across this pressure sensor while looking around
the Sparkfun site, and it could be good for altitude sensing:
http://www.sparkfun.com/commerce/product_info.php?products_id=8128
According to the specs it does 17-bit samples, which equates to a
resolution fine enough to measure the pressure difference in a 9cm air
column! It can only sustain a 1.8Hz sample rate at that res, but it can
also support a 15-bit mode in which it can do 9Hz updates.
It speaks SPI so perhaps it's worth investigating putting this on
ARTEMIS.
Cheers :-)
Luke Weston
I was thinking that we might just use something like the Freescale
MPX4115. This has an analog voltage output. A little bit of maths is
needed to convert voltage output into a pressure figure (and hence
into altitude from there.)
The MPX4115 can be had from DigiKey or Mouser for about $10 USD, which
is less than half the price of the above mentioned device from
Sparkfun.
I'm not sure what its measurement resolution would work out to be
though, probably inferior to that device.