A Wide Variety of free 1-wire slaves arriving soon. What do you need?

[StBarnabas]

Wookey
the 4 chips should correspond to the ones sent marked 1 2 and 3 (1-wire slaves) and a test flasher to check the electric energy meter 

[Alan]

Have induced R.F. Voltages been considered.
I found things worked to plan in the work shop but became unreliable in use. Even with screened cable and decoupling at sensors.

Just a ponder

Regards

Alan

[StBarnabas]

Hi Alan
more testing is needed - I will be very interested in how Wyleu and Wookey get on. Where I have run into problems is with the ADCs - using the 5V as V_ref does not seem to be good enough - I suspect some ripple on the power line. Eric is doing some work on this at present so it will interesting to see how he gets on.
Sean

[wyleu]

The flasher does indeed flash as described.

Chip 1, 1 Dual switch, identifies itself:-

28.182F05010000   28.182F05010000   directory
28.182F05010080   28.182F05010080   directory

And the light flashes twice when data is read.

Well Done.

For reference thats
black wire 0V to Green/White A pin 1 Orange/White B
red   wire +V to Green A pin 2  Orange B
green wire Data Blue A pin 4 Blue B

Do those 8P8C connectors make this confusig or what ?

[StBarnabas]

Excellent news. I wonder how Wookey is getting on?

[wookey]

Slowly. (decided to fix a whole load of things to build a new test balloon with latest kernel)

[wyleu]

I LOVE the LED on a onewire!

It takes so much of the guess work out of wiring stuff up !!

We must make a board for this...
Anyone used eagle enough to not have to learn it from scratch?

[StBarnabas]

The DS18B20 datasheet states that the temperature register format has 16 bits, the top 5 are sign bits and the bottom 11 bits 2^6,2^5....2^-3, 2^-4. Hence the maximum temperature reading is just under 128.
This however is not the way OneWireViewer in Java reads the data however. It assumes the MSB is a sign bit and the other 15 bits are 2^10,2^9..... 2^-3,2^-4. Giving a maximum temperature of just under 2048 degrees.  This property in conjunction with Eric’s 2 1-Wire devices on a single chip gives the possibility of a 32bit counter. (with a bit of post-processing).I haven’t tried this with either the C Version or with LogTemp or OWFS but it would be interesting to see how they behave. If there is sufficient time on could write to data EEPROM on the PIC and have a non volatile counter.
Sean

[StBarnabas]

Have had a bit of time. LogTemp gives 127.94 degrees  when the lower 15 bits are set. Onewire viewer gives nearly 2048 degrees
 

[wookey]

Excellent news. I wonder how Wookey is getting on?

OK. finger extracted and devices tested on my I2C-interfaced 1-wire network, using OWFS.

I thought it wasn't working for a bit, but realised after a while that not all the devices are the same. I can't download the word doc sean posted because the SMF downlaod function breaks on some browsers due to overfancy javascript. That might clarify what I should be expecting, but re-reading this thread has given me some clues (e.g the exstence of a 'quad' version, and some clues about inputs and outputs.

I did have one oops: Sean put one of the number labels on upside down and I failed to notice, so that one (chip '2') may be poorly after being powered backwards for the 1st 20 mins (until I noticed the smell of hot chip). In fact it does seem to be be still working, so we'll call that a useful robustness test :-)


Chip one attached
two extra devices:
/28.182F05010000
/28.182F05010080
(can read power, adress, type, crc and temperature/fasttemp/temperature12. crc and temp change with cheap ID)

Chip 2 (overheated)
/28.000000000000
/28.020000000000
/28.010000000000
/28.030000000000
(can read power, adress, type, crc and temperature/fasttemp/temperature12. crc and temp change with cheap ID)

Chip 3 attached:
/28.1A01010101EE
(can read power, address, type, temperature, fasttemp, family)

Chip 4 attached:
/28.1A01010101EE
mostly get 'data error', although did manage to read power, address, at least once, but not temperature, fasttemp (give 'data error')

Attaching chips 1,2 and 3 together they all were identified and I read the same numbers as addressing them separately.

So, in general it all works very well apart from chip 4, which sometimes (but not always) get identified, but I can't read any useful data from it. I have not seen values changing with inputs, but then I haven't changed any inputs, so that's OK.

Here is what I did in more detail. All of this was done with pin4 set to +5V as suggested by eric. I'm not sure what inputs/outptus I have on these chips, so I'm not going to try changing thing and reading lots of random values without someone telling me what to expect and test for :-) (maybe sending me that word doc would clarify?)

Other devices on other channels of the bus:
/10.B8E089010800
/10.62FC89010800
/10.73288A010800
/10.38158A010800
/10.C2E889010800
/10.AEEA89010800
/10.AD188A010800
/10.634B8A010800
/10.B33D8A010800
/10.BB4D8A010800
/10.E7EE89010800
/28.850874010000
/1D.48010E000000

Chip one attached
two extra devices:
/28.182F05010000
/28.182F05010080
owread -s localhost:4304 /28.182F05010000/power
1
owread -s localhost:4304 /28.182F05010000/die
C2
owread -s localhost:4304 /28.182F05010000/crc8
59
owread -s localhost:4304 /28.182F05010080/crc8
D5
owread -s localhost:4304 /28.182F05010080/die
C2
owread -s localhost:4304 /28.182F05010080/power
1
owread -s localhost:4304 /28.182F05010080/present
1
owread -s localhost:4304 /28.182F05010080/family
28
owread -s localhost:4304 /28.182F05010080/type
DS18B20
owread -s localhost:4304 /28.182F05010080/temperature
0
owread -s localhost:4304 /28.182F05010080/temperature12
0
owread -s localhost:4304 /28.182F05010080/temperatfasttemp
0

Chip 2 (overheated)
/28.000000000000
/28.020000000000
/28.010000000000
/28.030000000000
owread -s localhost:4304 /28.000000000000/power
1
owread -s localhost:4304 /28.000000000000/present
1
owread -s localhost:4304 /28.000000000000/type
DS18B20
owread -s localhost:4304 /28.000000000000/family
28
owread -s localhost:4304 /28.000000000000/temperature
4
owread -s localhost:4304 /28.010000000000/temperature12
9
owread -s localhost:4304 /28.020000000000/temperature12
14
owread -s localhost:4304 /28.030000000000/temperature12
19
owread -s localhost:4304 /28.000000000000/crc8
1E
owread -s localhost:4304 /28.020000000000/crc8
70
owread -s localhost:4304 /28.010000000000/crc8
29
owread -s localhost:4304 /28.030000000000/crc8
47

Chip 3 attached:
/28.1A01010101EE
owread -s localhost:4304 /28.1A01010101EE/power
1
owread -s localhost:4304 /28.1A01010101EE/temperature
255
owread -s localhost:4304 /28.1A01010101EE/trim
65535
owread -s localhost:4304 /28.1A01010101EE/r_address
51EE010101011A28
owread -s localhost:4304 /28.1A01010101EE/address
281A01010101EE5
owread -s localhost:4304 /28.1A01010101EE/family
28
owread -s localhost:4304 /28.1A01010101EE/type
DS18B20
owread -s localhost:4304 /28.1A01010101EE/present
1
owread -s localhost:4304 /28.1A01010101EE/fasttemp
255

[wookey]

Bum, just wrote a long post on design issue which got lost before posting.

Can't face typing it all in again now, so here's teh really short version. Issues covered: connectors:must find something better than 8P8C, and it's not 6P6C or 4P4C (they have the same height sockets).

I'd like to see a new family number used, and unique addresses (firmware generated by a web-page to make it easy and unique, like etherboot). In practice we probably need two versions - one for people who need convenience of re-using family 28, and one for people with free software who can use a new number and an interface not bodged on top of temp numbers.

Flavours I am interested in:
Switches, on/off sensors (possibly combined, as discussed in previous thread), energy sensors, both as counter (LED) and current sensor.

For rooms I want humidity and temp in each room, for a lot less money than the hobby-boards board, and using 5V not 12V. If we can attach the HIH3610 to a halfbee that would save cost of DS2438. I don't think this is hard at all.

Sorry that's rather brusque. Hope its still useful.

[wookey]

Klaus just kindly send me the word doc, which I have managed to turn into a useful format (PDF) (the day of the proprietary document format is past - will people please get with the program!). That does indeed clarify an enormous numer of questions about what these chips are supposed to be, what the pinouts are, why they are labelled 1 to 4 etc. I'll do some more tests now that I know what's what.

(Did I mention the bit where I get grumpy when people hide the good stuff in a proprietary doc format in an attachment hidden behind a javascript download scheme that only works with some browsers?). Yeah I know - I really shouldn't grumble when people are sending me free stuff that is even mostly documented :-), but a PDF online would be so much more easily accessible.

[StBarnabas]

Wookey
lack of time. I am no great fan of Microsoft either but forced to use it at work. I normally would convert to PDF but needed on this occasion to swap machines as I didn't have a PDF converter on the one I was using. I could have used LaTeX  but I'm not sure how many on the forum use it. Maybe you should ask Martin to ban any .doc .docx, .xls and .xlsx extensions?

I have now saved the attachment as .pdf

Klaus, thanks it looks as if the software is fairly robust. Hopefully Wookey can now do a few more checks but it looks as if things are going well so far.

Sean

[ericw]

Wookey,

Thanks for the test results - as the trial chips seem to have worked for everyone so far, it does look as though we have a sound foundation for building 1 wire slaves.

I'd like to see a new family number used, and unique addresses (firmware generated by a web-page to make it easy and unique, like etherboot). In practice we probably need two versions - one for people who need convenience of re-using family 28, and one for people with free software who can use a new number and an interface not bodged on top of temp numbers.

The prime object of the exercise was to enable people who were constrained to using off the shelf software to be able add additional functionality to their 1 Wire network without having to do anything to the software.

Once you broaden this to include people who are prepared to write their own master software an infinite variety of things become possible, so many in fact that its not possible to satisfy everyones individual needs.
So far the chips have been read only (although have I checked the 'write scratchpad' functionality), however by allowing the user to write to the builtin EEPROM,  it is possible to create a chip which is user configurable .

I would envisage being able to configure things like :-
ROMID
Output is from TMR2 counter
Output is from ADC
Output is direct from pins
Configure spare pins as  digital input, analog input to ADC, digital output

This ought to enable to satisfy the needs of basic sensing for those who can/want to do their own thing at the master end. Whether the 1-Wire is the best bus to use is of course another debate.

As far as humidity sensing goes its fairly easy with the Honeywell HIH sensors but still expensive (HIH5030 seems to be cheapest @ £8) compared with the complete humidity and temperature displays you can get on Ebay for £4. There are cheaper sensors (~£1.50) on Ebay but they have wide tolerances so would almost certainly need to have some sort of calibration step done before thay are viable. They also need a bit more circuitry than just sticking onto an analog input.

As far a wiring goes I find that standard telephone extension stuff works fine, you can get both Tees and male and female connectors attached to intervening lengths of cable, which you cut and insert your sensor(s) for daisy-chaining. Its all very cheap, easily obtainable and you don't have to worry about crimping on the connectors. Yes - you do need an adaptor to fit the USB dongle to get at the 5v supply - I hacked an old modem lead which had the facility to disconnect the phone to get mine.



 

[wookey]

Eirc - if we can configure dynamically then that'd be great and should satisfy everyone.

As you say, everything seems to be working fine on all available interfaces/softwares so that's definately good enough. Well done that man - this is a very fine piece of work.

Hmm, yes I see what you mean about the honeywell humidity sensors not being cheap. (£20 from RS!). Still, if it's just an extra £8 or so per sensor that's tolerable. No idea how accurate sensors have to be for household use - probably not very. (10%?)