Some ideas for a domestic antitheft system... and probably more.

Is all this just to avoid running two more wires?

The Pyxos system does this, last time I looked you needed 27 components to interface to the wires and one of them is a dedicated processor. So this is not an easy problem to solve.

OTOH having RS-485 on extra wires is an easy problem.

That said I was a poster on that TI forum you referenced and the TI tech did make it sound easy to inject RS-485 onto to DC bus.


Rob

Hi Rob,

we were looking for SN75176 and others. Our concern was on collision, if two transmitter starts to write at same time one of them can be damaged, if the output drivers are not protected against this. For that reason we added a resistor on the output drive, but in this case, with the RS485 transciver we will never read a collision, because an external resistor will be applied on both RX and TX.

After your post, I've looked in detail to the equivalent scheme of the outputs for SN75176, but the schematic on the datasheet is not clear enough for me. Typically the RS485 is designed for Master/Slave communication, so is assumed that no collision may happen.
One more concern on the RS485 is the differential transmission, that makes things a bit more difficult when this shall be moved over a powered bus.

Just to recap, now we are planning an binary FSK over a 24V bus. The modulation and demodulation will be performed in hardware, using the internal resources of the ATmega328.

Now the goal is find out an electrical schematic to move the FSK over the bus. In the proposed schematic, we have used a MOSFET driver coupling via a capacitor to the bus, this works nice but has one issue: the protective resistor on the output driver will reduce the voltage range on the modulated signal. More are connected to the bus less is the voltage range, so we are recap for tri-state drivers.

Does you have suggestion?

Thanks.

Regards,
Dario.

Does you have suggestion?

What you are currently doing is a bit analogue for me :slight_smile:

Re the RS-485, collisions are an issue with any system that doesn't release the bus for one of the logic levels, typically this is handled by using open an collector/drain configuration as you know.

RS-485 transceivers can be wired to do this by connecting the transmitter input to 5V and running the data to TE. Thus the outputs go tri-state when the data is low and are driven when the data is high (or is it the other way around, no matter). This requires fail safe termination (two more resistors) of course.


Rob

Graynomad:
What you are currently doing is a bit analogue for me :slight_smile:

:slight_smile:

Graynomad:
Re the RS-485, collisions are an issue with any system that doesn't release the bus for one of the logic levels, typically this is handled by using open an collector/drain configuration as you know.

RS-485 transceivers can be wired to do this by connecting the transmitter input to 5V and running the data to TE. Thus the outputs go tri-state when the data is low and are driven when the data is high (or is it the other way around, no matter). This requires fail safe termination (two more resistors) of course.

We have thinked about open drain solution, but it gets a nightmare with a powered bus. The main problem is that I can rise the voltage above the 24V when I'm transmitting HIGH, but I cannot rise it down when I transmit LOW.

I've fight a lot against this solution, but nothis was working for me, maybe I've just wrong the schematic.

Any help or suggestion is appreciated.

Regards,
Dario.

Hi Dario, Hi Rob.

@Rob: Welcome and thanks for reading/commenting this thread that started with some easy proposals and moves to a set of interesting ideas!
@Dario: Thank you for your recap on what we are doing

I've attached a schematics that should (I hope) explain what I've in mind. I'm sorry but I don't have the proper symbols for the drivers so I've used a general set. I've also searched some possible components in the market could easily do the job without "consuming" space on the PCB.
I would like to leave free as much as possible the pins on the Atmel so people could use it like on the "standard" Arduino boards. For this reason I'm proposing a schematic that uses external components.

Here is a brief explanation on what I'm proposing.
Let's start on the left side where the FSK modulated output is branched. One leg goes to a three state buffer (the proposed NC7S125 is able to drive a max of 32mAmps, half than what's performed by a 485 transceiver). The other leg goes through a diode on a simple RC stage. The zener is placed here to limit the voltage across C1. The output of the RC stage goes into a NL17SZ17 implementing a Schmitt triggered buffer. His output is used to enable the line driver, attached to the buffer through the R3 (a limiting resistor) and C2 (the decoupling capacitor). In the RC I've added the R2 needed to discharge C1 when the modulated signal stops. I think R1 should be greater than R2 but should be small as possibile in order to have a fast discharge.

On the receiver side the modulated signal coming from the bus is feed from C2 to a not inverting op amp amplifier. This is usefull for two reasons: the first is that it has a very high impedange (so it's not charging the bus) the second is that it can be used to easily apply the required Vcc/2 offset. Vcc/2 is generated by IC2A (it can be replaced by a resistor set and a capacitor butan op amp will present a very low impedance). R6 could be very high (like 100kohms) in order to limit the current sink from the bus.
The op amp gain should be useful to recover a squared modulated signal.

I think that the schematics is missing some diodes to protect output and input stages. Unfortunately it's a little bit complex...

What do you think about? Suggestions?

Thanks!

Marco Signorini.

Hi Marco,

I agree in the use of the opamp to lower the input inpedence for the input, but I would willing to use the smith IC to rectify the output of IC2B before goes into the uC. On the other hand, R1-C1 will smooth the FSKOUT signal due to the internal resistance of the output pin of the uC.

So, IMHO, use a dedicated pin (like one tipically used for the analog input, configured as digout) for the tri-state enable it would be a safer option.

Thanks.

Regards,
Dario.

Regarding the coils, the magnetic flux is basically dependent on the geometry of the coil and the current. The coil shall be selected to work in the linear zone, that depend on the drawn current, this will prevent a coil saturation.

The current is related to the number of devices, so there are two options:

  • Use a coil that work in the linear zone for the maximum current allowed on the bus (assuming max number of devices), or
  • Use a coil rate based on the number of real devices.

The first solution is the best one, but will lead a bigger cost and space. I suppose that in commercial devices, the coil is embeed into the bus power supply.

Regards,
Dario.

Use a coil that work in the linear zone for the maximum current allowed on the bus

How does this handle < max nodes, say just 2.

Use a coil rate based on the number of real devices.

Not practical in the real world I think.


Rob

Hi Dario and Rob.

I think is just a matter of finding the best compromise... the best would be to have coils running on linear zone... anything that differs from this situation should work "not bad".
In the real world, inductors are not only the one we add on the power supply... but "virtual" inductors are added by the cable used on the bus... I mean, I'm expecting that in a working installation a lot of variables will be injected by the bus configuration and other and the real situation we will have will be slightly different from what we are simulating with software tools and/or test benches.

I would start testing with a "normal" ferrite based coil rated for more than 2A at the supply side; hundred of mAmps at the board side. With a signal generator and a driver I can inject a signal and measure it on the scope, either coupling on AC with a capacitor, than directly on the bus, than on the cold and hot side of each inductor.

I'll do as soon I'll be able to have here all needed components (and time).

@Dario. At the very beginning, the RS485 output enable pin was already connected on PB1. We can opt to have the same OE either for the new driver. This will reduce the number of components used (no RC integration for the enable signal generation) but requires a total of four pins for the data handling. It's a huge number of pins... but on the other side this allows the programmer to properly control the bus management.

@Dario again: about using the Schmitt trigger on the output of the op amp used for the receiver... I'm not sure it will be so useful. We already can define what's the level discriminating the zero or one on the incoming side through the selection of a reference voltage applied to the analog comparator inside the Atmel. We can assign this voltage to a little bit more than Vcc/2. We can also define the offset applied at the output of the decoupling capacitor to be a little less than Vcc/2. We can increase the gain of the op amp in order to have it working in the saturation zone for signal with amplitude more than, I don't know, 3/4Vcc. The full system (op amp + comparator) will work as a sort of Schmitt trigger (or something similar) for our purposes....

Thanks!

Hi Marco,

yes we are not considering the bus itselft, it shall act basically as a filter lowering the overall signal amplitude. Phase and delay should not care since we are using an FSK. The coils behavior shall not be affected from the line, because depends on magnetic core characterist.

Relevant the pins, it depends on what you would like to lose, could be an analog or a digital; also if you are using two more pins compared to the first design, you have the serial port available for quick debugging or online configuration.

I agree on the opamp, as per your proposal you may avoid the use of the smith trigger.

I will start the development of the FSK driver as soon I will close the actual release of the framework.

Thanks.

Regards,
Dario.

Hi!

I tried to follow all the ideas generated by this thread and I've created an LTSpice simulation testbench. I would like to share with the Community the results, so I've created a github repository and I've placed the LTSpice source file on it. You can find the public github repository at this link: GitHub - ethermania/FSKonDCbus: Low speed FSK over 24VDC bus for domotics systems based on ATMega328 devices. Comments and contributions are welcomed!

Here is a brief explanation on what you can find on the file.

  • A bus with parasitic capacitor (C4), resistor (R10) and a 50Hz 5V sine superimposed to simulate the effects of a possible noise on the line
  • A MOSFet simulated Three state buffer injecting FSK on bus, with a protection resistor (R1). Note that the output stage generates a little short-circuit on the transitions. This is not important because this stage will be probably replaced.
  • An Rx stage composed by a banbpass filter and the hypothetical comparator embedded on the Atmel processor
  • A suitable power supply retrieving 5V from the bus, used to supply either the Tx than the Rx stages. A load resistor (R11) is added to simulate a realistic 0.5A consumption
  • A set of 4 power supplies, with a 0.5A load, added to simulate other 4 nodes on the bus sinking (a lot) of current.

Running the simulation is the best option to understand what's happening on each stage. The most important thinks I can resume here are:

  • At the Tx stage the current drawn by the bus is around 30mAmps. It's more than the maximum provided by the driver I've proposed on my previous post. Increasing the resistor R1 will limit the current but reduces the injected FSK voltage increasing the probability of a not well recovered at the Rx stage
  • At the Rx stage is mandatory to have a band-pass filter in order to increase a little bit the noise immunity. Best would be to have two bandpasses centered at the FSK frequency (7.35kHz and 4.9kHz) each one, but this will increase the required components. I've added a simple 1st order active bandpass filter centered at 6kHz, with a gain of 12dB, with low cutoff frequency at 4kHz and high cutoff frequency at 8kHz. This increased (a lot) the overall Rx performances.
  • The effect of a parasitic capacitors on the bus (I've set it at 1uF that's very huge.. I'm not expect to have something so big in the real world) is not dramatic. It decreases the overall FSK voltage at the Rx stage and increases the current sink from the Tx.
  • The effect of a series resistor, introduced by the cable on the bus, is not interesting.
  • The effect of a superimposed 50Hz (I've tested a superimposed value of 5V over the 24V of the bus. I think is very high compared on what we can find on the real world) is to change the duty cycle of the recovered signal. Not the frequency (as expected). When no data is present, a set of spurious transitions are generated by the comparator. They should be discarded by the soft-modem library (it's already performing like that).
  • Coils characteristics are very important. I used a simulated real world coils I've found on the provided library and not a general coils.
  • I've added a set of power supplies to simulate what's happening on the bus when more than one device is added. This power supplies are made by normal linear regulators so the current drawn from the bus is higher than what is expected.
  • The current sink by the Rx stage is so low that's not important.

I've attached the schematics and the results of a simulation. In the simulation is present the decoded signal (green), the incoming signal from the bus (the blue, with a big 50Hz superimposed). The red line is the output of the bandpass filter (the signal will be feed on the Atmel pin).

Thank you for following me.
Marco Signorini

Hi Marco,

about the tri-state buffer, I think that a more suitable equivalent scheme may be this one, where basically both the drivers of the CMOS output are disabled.

Rather, from the graphs looks that the voltage transferred from the source to the bus is too low, and that may create problem due to hysteresis in the comparator.

The FSK wave equivalent circuit for our scheme is an RLC where the bus voltage is equal to the coil voltage, so we can use a frequency analysis for the ratio between the coil voltage (VL) and the input voltage (V).

Is too hard write the complete formula in this forum, but considering the first harmonic of the FSK wave at frequency omega (rad/s):
omega->0, VL/V->0 ;
omega=omega0=sqr(1/(LC)), VL/V=omega*L/R and I=V/R (max current) ;
omega=omega1=R/L, VL/V ->1 ;
omega>>omega1, VL/V = 1.

To size properly the components we may start with the max current I=V/R, using R=270 Ohm we have no more than I=18mA at omega=omega0. The omega0 condition is the resonance of the RLC and from this frequency the ratio start to increase.

Assuming to use two waves at 4 KHz and 7 KHz, we may define omega1=3 KHz (about 20 K rad/s), so the FSK waves will have a high gain on the bus. The L = R/omega1 is about 13 mH.
So, we have to use a C value that give us omega0<omega1. Using C = 1uF we have omega0 = 1.5 KHz.
Using R=270 Ohm, L=13mH, C= 1uF the current will be always lower than 18 mA and the FSK waves will have a VL/V ratio near to 1. Than the bandpass filter will cut the noise that may be on the bus.

I don't know which are the commercial values available for the coils, but something in that range shall be used. Does you have the commercial values table?

I haven't tried to simulate the circuit with that numbers, so I may be wrong on that. I will try as soon these numbers.

Please let me know your opinion.

Thanks for sharing.

Regards,
Dario.

Hi Dario.
Effectively the inductors I've placed on the first revision of the simulation file are not correct. Yesterday I've got the same conclusions you wrote in your last post. I've simplified the overall schematics in a piece of paper and I could now better understand how currents flows on the circuit. I've then manually calculated the reactances for inductors and for the equivalent circuit.

The problem is that, adding more boards, the overall impedance "seen" by the transmitting board falls down: each board is a "resistor" that adds in parallel to the bus. The overall impedance seen by the transmitter is a set of parallel impedances made by the power supply and the boards.

Increasing the inductors size will reduce the problem because it increases the impedance introduced by each board in the bus.

I've found on the market some inductors with physical size compatible with PCB restricted size. They're in the range of 6.8mH, with an overall current of 0.15Amps. For the power supply I can find a 33mH rated at 1.5Amps.
For higher values, the physical size of the inductor is too big and the inductor is too costly.

If you run the simulation you can see that so big inductors introduces a lot of "artifacts" at the beginning and at the end of the modulated signal. A 50Hz superimposed on the voltage bus is catastrophic :frowning:

With a commercial three state buffer we can manage up to 30mAmps... so the budget is very limited.

I'm start to thinking that the overall proposed solution is not affordable due to costs and/or technical problems.
I have to think about.

Thanks!
Marco Signorini.

Hi Marco,

Mmmmh... I didn't got the point.

We have one big coil that is the load for the bus, that shall be rated in 10-30 mH and one more coil for each board that shall create us problems.

The filtering used for the power supply is an LC an so can be sized as bandpass filter that shall be out of the FSK frequencies. The DC/DC converter it self is equivalent to a resistance of 240 Ohm. So we have L-C//R (where - is series, // parallel).

Using a uH coil and 220uC capacitor we should be in the safe zone (I haven't calculated this, just smelling the numbers!).

Could you please post some capture of these "artifacts", because in my simulation (with my scheme) and 35mH coils I've a quite nice signal. Also the 50Hz should be a low enough frequency to be out of our filtering band.

In your previous schematic, using 220uH coils and 1uF capacitor you were in the rage 10-86 KHz (omega0, omega1) so the 50 Hz should be out of these problem. Maybe you are finding this using new values?

If you have time, please try the numbers that I've proposed. I will try to do the same within this week.

Never give up!!! We are not so far from the goal!

Regards,
Dario.

Hi Dario.

You said:

In your previous schematic, using 220uH coils and 1uF capacitor you were in the rage 10-86 KHz (omega0, omega1) so the 50 Hz should be out of these problem. Maybe you are finding this using new values?

Yes. If you have time, please download the latest github simulation version and change the 24V bus supply with a 24V+5sin(50Hz) generator. Look at the voltage before and after the passband filter. It was late when I did it yesterday, so probably I did errors, but I remember something I wouldn't see... :frowning:

If you have time, please try the numbers that I've proposed.

I did it and I can confirm that the current flowing from the driver is compatible with your results. Unfortunately is not so easy to find a 13mH cheap and small inductor... so I used a 6.8mH inductor in the simulation. The current handled by the driver is reasonably small enough for a commercial unit.

... but...

I don't think that increasing the inductor is the correct way to have something cheap and reliable. If I well understood, we can have the same effect we have increasing the inductor size if we increase the injected signal frequency. If we can rise the modulated signal frequency to something about, for example, a MHz, the inductor reactance will be multiplied by a factor of 100. This let us able to reduce the inductor size.

I know it's impossible to demodulate by software any FSK signal within a MHz range but we can use a MHz carrier to replace the high level of generated FSK. I mean... it's like placing an OOK modulation on top of the FSK.

The receiver side would be a pass band centered on the MHz carrier followed by an integrator and the usual Shmitt thrigger. The recovered FSK signal would be demodulated as before.
The circuit is a little bit complex but I think it could perform better than what's actually doing.

What do you think about?

Thanks!
Marco Signorini.

did anyone get domestic home to work over the internet?

Hi Marco,

in the while, I've worked a bit on the drivers for the FSK and I have some code with collision avoidance that is working. Is not complete, because still miss the checksum, and for sure require more test. I've used it in a small setup with three nodes and a few centimeter bus, without additional hardware controllers.

I've decided to include this code as preliminary in the release A3.1 of Souliss, that is now available for download.

In the mean time, I've spent some time on the hardware side, has we discussed there are some ideas, but still there is some work to understand how fit your requirements on the size of inductors.

Regards,
Dario.

Hi Dario, hi All.
Sorry for the late answer to this thread I started a long time ago... but holidays and other jobs have taken precedence.

I would like to summarize the point where we are and what we understood by discussing on this topic.

We started the idea to develop an Arduino based system targeted to antitheft systems. The first approach was to develop a multi purposes Arduino with some relays, digital and analog inputs, digital outputs, a power supply and an RS485 based communication interface onboard. The main goal was to produce a board able to fit into a standard European 503 box so people could place it anywhere in the house. The RS485 was chosen because it's a well known standard, used on many commercial antitheft systems as main field bus.
We developed two version of that systems. The first version was build around a linear power supply that was replaced by a switching power supply on the second version. I've personally build two units fully working (some pictures are still at the EtherMania Blog) and I've developed a library useful to easy control the onboard SPI expander.
Suggestions came by this thread allow me to change a little bit the original target: the final unit I've on my desk mounts a set of Arduino's compatible headers that allow people to use the board not only for antitheft systems, but as a main block to develop/prototype domotics applications.
And that was the incipit...

but... we wanted more....

We started speaking to replace the RS485 transceiver with a custom communication system that should provide the power required by each board and allow multimaster communications between boards. This should be done through a simple twisted pair, thus reducing the connection complexity. The idea is to have a distributed system where all boards are connected together by a "simple two wire cable" altogether connected in a multiple star topology and, luckily, not terminated.
We don't need super high transfer rates: we need to be able to transfer only actuation commands and other possible parameters like the status of a remote switch, temperature and so on.

Summarizing the full thread contents I can say that:

  • we opted for a modulation system based on FSK. Two different symbols for the 0 and 1 bit statuses. The modulation is simple. The demodulation could be done through an hardware comparator embedded on the Atmel micro and measuring the timing between incoming frontends. We can do some hardware assisted time measures so they are enough accurate for the purpose.
  • we defined a physical layer based on a set of capacitors, inductors, drivers and comparators/filters. The first were used to decouple either the Tx either the Rx stages from the DC on the bus; the inductors were used to provide high impedance to the FSK signal when feed into the main and distributed power supplies. Push pull drivers were used to "inject" the FSK over the DC line and comparators and active filters were used to filter out and square the incoming Rx signal.

This solution was very interesting and strong enough to produce good results in the simulated environment. We were able to transmit and receive the simulated FSK signal between nodes connected together by simulated cable (with some added resistors and inductors to simulate a real working situation).
Unfortunately this is not something that could be easily replicated in the real world. The proposed circuits work well when large inductors are used. Inductors are big and not cheap. Large inductors are not "friends" of electronic systems because they introduce spikes, high voltages and currents.

So we ended up with a NO valid solution but with a lot of information and experience that I would like to use to start a new thread because I think that here we're now out of topic.

The new topic is here: http://arduino.cc/forum/index.php/topic,121868.0.html

start a new thread

Start away, I lost interest when the interface got into the unfamiliar (for me) territory of inductors and transistors.


Rob