Current Cost Support Forum

_________________
Seeker
"The Truth is out there!"

Hi Seeker,

I see a few problems with your circuit but the most important one of all, is that op-amp U1A will not perform how you are expecting it to. The reason i say this is because it is operating at full open loop gain with it having no feedback resistors. For this particular section to work as you intend, you would need U1A connected in a differential amp configuration using an additional 4 resistors. In it's present configuration, as soon as there is a fraction of a difference between the + and - inputs the op-amp output will saturate and swing fully high or low. You also need a resistor from the supply down to the LM335. The LM335 acts like a temperature controlled zenner diode. (although i'm sure you already know this)

I beleive the whole circuit could be made much more simple but unfortunately i haven't got a drawing program on this computer to be able to put my ideas accross.

I was also under the impression that the Analogue boards output a reading of 0-500 watts or am i confusing that with the Digital boards?

I had an idea the other night after my last post, that if say 6 volts is used, center tapped to effectively give two 3V supplies in series. The center tap would connect to the negative of the dev board and the +3v side to the positive of the devboard. The 6V series combination of the cells would be used to supply the LM335. By doing this the negative side of the LM335 is sitting -3V lower than the center tap (which is the dev board negative rail) and therefore at about 27 degrees C the devboard input would be at the equivalent of zero volts. The negative half of the supply could actually be shunted to -2v7 using a zenner and series resistor to give you virtually 0v output at 0 degrees C and respectively 1v output from the LM335 at 100 degrees and not a single op-amp needed at all.

Of course there is the matter of any gain that may be required if the dev board needs an input greater than 1v to give the correct reading but a single op-amp could provide that and driven off the split rail supply of +/- 3 volts it would trim down to zero perfectly as it's right in the center of it's effective output range.

It could also be the case that you might actually need a bit more than +/- 3V to get a reasonable output swing from the op-amp but this is where i say a rail to rail opamp may help if voltages are to be kept low.

Keep any resistor values in feedback loops, high in value, this will reduce power consumption, although, too high in value and the outputs will be less predictable due to the input bias currents of the op-amp loading the resitor values.

FET based op-amps use less current than LM324's and if only a single op-amp is needed this will obiously use less current than the 4 in the LM324.

Just some food for thought anyway.

I'm not intending to offend or critisise the circuit other than in a constructive (hopefully) way.

It's very hard to put the description of my ideas into words so i hope i haven't caused any confusion. My idea may not even be very viable it was just something i quicky drempt up, on my way to bed.

_________________
Seeker
"The Truth is out there!"

That's a fair bit of work just for a temperature sensor. It looks like it'd make more sense to rework the code on a dev board and then use a digital sensor (DS18S20 or similar perhaps) to pick up the temperature. How far did you get implementing your sensor?

I'd posted that last post at the risk of someone saying "why don't you write something", which no-one has done (yet). I spent a bit of time with a digital dev board, a bus pirate and the EnviR - and together with the info that Jack Kelly put on his blog, I've managed to produce some basic code that can handle transmitting data and pairing. It's written using MPLABX and the XC8 compiler, so it's mostly C code. There's little in the way of optimising though.

I did discover that the digital dev board has a pulldown on its input pin, so if you did want to use a 1 wire device, you'd need to remove the pulldown and instate a pullup instead. I haven't written any code for that yet!

I put together the protocol that I'd uncovered on Jack's github wiki pages, which is here: https://github.com/JackKelly/rfm_edf_ec ... F-protocol

I've also threw together some firmware at http://www.aoaforums.com/forum/519245-post14.html - the pinout for the ICSP connector is in that thread too, although you'll need to switch to viewing the whole thread. This board doesn't seem to like more than two links in a post.

Well, I guess i can safely say you are the kind soul who has invested a lot more time than i have.

The work you have done is excellent and will be very helpfull to many including myself, so i can only offer a humble thanks very much to you for your efforts so far, but i sincerely do appreciate it.

A fair portion of the info you have presented, i had already worked out for myself from my own experiments BUT not in as much detail as you have done and i haven't documented it other than on a few scraps of paper which are buried under a several dozen other scraps of paper with yet more odds and ends on.... you get the picture i'm sure.

I'm glad you have spoken up here and brought these things up, opening my eyes to others such as yourself who have been doing similar work to what i have done. I didn't think there was much interest in this so i have kept things to myself so far. Certainly until i knew for sure that i was correct with various bits in each byte of the data packet etc.

With the Digi dev board however, when i was looking at the dissasembly listing of the original code, i did notice that the preamble had more than just a single byte before the synchron word. I can't remember how many off the top of my head but 5 bytes rings a bell. At this point in time i have only analysed the SPI data on the EnviR and not done any analasys with the transmission side of things to confirm it.

The HopeRF modules seem to use the TXC101 and RXC101 for their controllers. The datasheets for these seem to suggest a preamble of one or two bytes of an alternating bit pattern (0x55 or 0xAA). That seems depends on the setting for the CR lock. Fast CR lock suggests a single byte for synchronisation, whereas slow CR lock suggests two bytes. From the captures I did, I don't remember seeing more than one sync byte. It was a bit of a pain, as the nIRQ line doesn't remain active very long.

I was aware that the PIC wasn't code locked, but to be honest, reverse engineering code isn't my strength! It was easier (for me) to work out the protocol by watching what went on and then write completely new code to do that. I'm pretty sure there's probably things I've missed.