Use cheap little 433mhz OOK transmitters and receivers to link your sparks up

[Bluebie]

I made a few tiny mods to this arduino library: https://github.com/Bluebie/arduino-libs-manchester to make it extra compatible with Digispark. It works with 8mhz, 16mhz, and the normal 16.5mhz clock speeds. You can use it to transmit or receive messages via these sort of little transmitters and receivers which cost only a couple of dollars for each transmitter and receiver, but they get interference from doorbell buttons and stuff so they're good for stuff like a little remote sensor where you don't mind if it looses it's messages for a moment here and there.


With this library they send about 500 bits per second, and it includes example sketches for simply sending integers, but the library supports sending byte arrays (like strings!) too. It's just kinda a crummy medium for strings because it's pretty slow.


Also be aware that it is good common decency to not spend more than a quarter of each second broadcasting on this frequency, because otherwise you may disable your neighbors wireless doorbell..


The digispark has a built in temperature sensor! I bet it'd be possible to make a little wireless thermometer gadget just by plugging one of those transmitters in to the digital pins (except the antenna pin which could hang off the side) and hooking a battery up to the power pins! Could be neat with an added solar cell! Digispark set to 8mhz with the power LED disabled needs only about 10 milliamps, with transmitter probably about 20ma all up, so you could easily run it from a little solar cell, maybe with a NiMH battery to run it through the night. You could do other sorts of sensors like soil moisture or simple door open/shut magnetic reed switch ones pretty easily too! Or maybe attach one without a battery, just off solar to your cat's collar and find out how much time your cat spends lazing in the sun!


Hehe. Anyone going to do something fun with this library? I'm using it to hook my backpack up to my motorbike so some florapixels on my bag light up mirroring the blinkers and brake lights, since I already have florapixels on my backpack most of the time anyway (my fox ears travel on my bag when I drive)

[dougal]

The digispark has a built in temperature sensor!

Say what? How did I not know this? How do we get to the data?


(I guess I need to take a look at the data sheets and such, eh?)

[Bluebie]

I tried to figure out how once, but it didn't work. If you figure it out let me know!


Basically the internal temperature sensor is on it's own ADC channel, but you have to set the ADC in to a particular mode (using 1.1v reference and stuff) before it works. I'm not sure what else is required. It exists primarily so the chip can compensate for the way it's clock speed drifts at different temperatures by under/overclocking itself relative to ambient temperature.


Digisparks don't take advantage of that capability. Very few things do. Also as a little side note, as of Digispark Arduino app version 1.0.4 (the recently released one) you can use the warranty-voiding Burn Bootloader option in the tools menu to upgrade the bootloader in your digisparks from 1.02 to 1.06. This version fixes the clock speed to be much more precise when the spark is powered off batteries or a phone charger type of gadget rather than a living breathing computer's USB port. Just the other day a major contributor to the bootloader project (embedded-creations) told me he's figured out a way to shave a bunch of space off the bootloader too, so the next version of the IDE should give you some extra program space to play with as well, if all goes to plan! ^^


With the 1.06 version bootloader to get the clock speed as precise as possible, upload your sketch to the digispark while it's at roughly the same temperature as the place you'll be using it later. The clock speed calibration setting is updated every time a sketch is uploaded.

[bobricius]

I hear that internal temperature sensor is very inaccurate. Is Manchester library better than WirtualWire? Is internal RC oscialator sufficiently accurate and stable for wireless comunication if I create outdoor thermometer form -20 to +40 celsius?

[dougal]

Oh well, I guess I'll still go ahead with my plan to hook up external temperature sensors, then.

[Bluebie]

Internal sensor has to be calibrated (so you put the chip in an environment with a known temperature and see what the number is), but after that it should be fine.


Manchester library was made specifically because VirtualWire is not good at dealing with imprescise CPU clock speeds. I don't know. I haven't tried VirtualWire. Maybe the clock speed is good enough most of the time with the new clock fixed 1.06 bootloader mod, but I think it's better to use something designed to be more tollerant. Manchester library has explicit attiny85 support - my changes just optimise it a little to run well on the 8, 16, and 16.5mhz clock speeds supported by digispark - the library originally only supported 8mhz and didn't warn you if you built it for a different speed - it would just not work right.

[dougal]

To get back on topic, thanks for the tip on those OOKs. I just ordered 3 tx/rx pairs.


Also ordered some bluetooth modules and other goodies. I've gone a little nuts lately. It's been fun getting back into electronics. I hadn't played with stuff like this for about 30 years, unless you count a brief infatuation with micro RC cars about 10 years ago.

[microtherion]

I tried to figure out how once, but it didn't work. If you figure it out let me know!


Basically the internal temperature sensor is on it's own ADC channel, but you have to set the ADC in to a particular mode (using 1.1v reference and stuff) before it works. I'm not sure what else is required. It exists primarily so the chip can compensate for the way it's clock speed drifts at different temperatures by under/overclocking itself relative to ambient temperature.

I haven’t tried that precise experiment, but it could be as simple as:

analogReference(INTERNAL1V1);
analogRead(A0+15);

On the regular Arduino core, analogRead() goes to great lengths to prevent users from being able to pass in things like the temperature sensor or the internal reference voltage as ADC sources, but the arduino-tiny validation is much simpler, so the above should be fine to select source B1111.

I’ve never read an internal temperature sensor, but I once read the internal voltage reference on a Lilypad using a similar technique.

[digistump]

Since this went off topic (in a great way!) - Dougal's response has been split into a new thread here: http://digistump.com/board/index.php/topic,893.0.html so that we can have a new thread to discuss the internal temp sensor and how to read it.

[Bluebie]

For whatever it's worth, sticking a 433mhz transmitter in the headlight of a motorbike and a receiver in your backpack doesn't work well. It seems to work fine when there are surfaces to bounce off but in open space it's no good.


Pondering redoing my backpack thing using infrared - I think I figured out a way to do it using the manchester library too!

[Mark]

Bluebie
At 433Mhz a 1/4 wavelength is around 172-175mm.
The metal surface (the headlight reflector) will be de-tuning the antenna, and also preventing any radiation other than directly forward.

There are smaller versions of the antenna using tuned coils, but the 1/4 wavelength is still around 172-175mm, so capacitive objects within this will have some impact.

My suggestion would be to see if you can fit it in the rear tailight.
If the rear of your motorbike is plastic, then you could also use a conductive tape to make the radiating element of an antenna, or mount a small whip.

Mark

[Bluebie]

by "in the headlight" I mean behind the headlight. My bike is a Honda CT110, which has a plastic cover over the back of the headlight where most of the wiring ends up. It's a great place to install stuff because it is reasonably protected from the weather and has access to nearly every wire in the entire system. I originally intended to install the radio in to the taillight but I'm disturbed by how tricky it is to get it working well, so I'm going to try infrared first. I think using this manchester library I'll be able to use tone() to output a 37khz square wave on one pin, and output data on another pin, and combine the two using two NPN transistors to drive an array of IR LEDs which will shine on my chest when I sit on the bike. I'll then add one or possibly two infrared receivers to the straps on my backpack in the usual curled up legs wearables style, and hopefully that will be much more reliable and I wont feel like every time I use the brakes on my bike I could be signal jamming everyone's wireless doorbells in the area


Infrared and 433mhz OOK radios seem to work on almost all the same principals with AGC and such, so I think this library should work well for it. To the experiments!

[Mark]

Bluebie
I know the bike you mean, but not intimately.
I'm still picking that the close proximity of wires that are basically earth to RF signals may be affecting your range.
If you can try it so the aerial is clear first, then you might have a fighting chance.

The 433Mhz wireless units I have been playing with (using RCSwitch library) send a 24bit code.(or whatever you want)
The library has the ability to send it however many times you specify.
http://digistump.com/board/index.php/topic,371.msg1904.html#msg1904

So for my application I sent it three times (I think), and for the original Home Minder it sent every 10 secs for a minute.

You certainly have the right idea to not continuously transmit, as I understand part of the licensing is at x duty cycle.

Mark