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

Hi Marco,

yes is a suitable solution if tri-state is not used. Regading the overall voltage transferred, you are right, it will change with the number of devices connected on the bus. On the proposed circuit, the MOS state is inverting type, so when not used, the pin is a 5V and not at 0V. This means that there is no sink, but a source, that will rise the overall voltage. Increasing the number of devices, the lower values of the wave will move near 5V and this may lead a miss communication.

The problem can be solved with tri-state devices, used only for the TX. The problem is that it will require one more pin to set the third state, or we have to enable the third state only when there is no output wave, but I've no idea on how get this.

Any idea?

Back on the coils, is my assumption right?

Thanks.

Regards,
Dario.

Hi Dario.

Yes, being inverting or not inverting is not important... the problem is the same on either conditions. I think this is not a valid solution so we need to think to use a three state driver to allow boards that are not transmitting to detach from the bus.
I'm thinking to something that generates the three-state enable signal without requiring a dedicated pin on the board. Let's imagine to generate a carrier trailer on modulated signal: we can integrate the modulated signal with a "simple" RC circuit used to enable a three state driver. The RC could be driven by a diode connected to the gate of the driver. As soon as the trailer is detected, the enable signal is generated. As soon as the modulated signal stops, the enable signal falls down and disables the output buffer.
We can try to understand what's the minimum RC time required to have a working solution without affecting too much on the data transfer... Adding a Schmitt trigger will probably enhance the performances...

About the coil, unfortunately I don't have any experience on that... so probably the best option is to ask to the Community or setup a test-bench.
I plan to use a normal SMD coil made on a ferrite core.

Thanks!
Marco Signorini.

Hi Marco,

yes is a good idea. My only concern is how to find out if the carrier came from it-own pin or came from the bus, when you have time, please propose a schematic. So it will be easier find out how.

I will study a bit the saturation for the coils, because the ferrite core may be saturated.

Thanks.

Regards,
Dario.

Hi Marco,

are you planning to use analogs for this or next boards?. In ATmega uC some pins can work as analog input or digital I/O, so we may use these pins for the tri-state select.

In our case, if we leave the RX as is, we just need one more pin to enable or not the TX. Also in case of tri-state, we may need the resistor to protect the output drivers in case of two transmission at same time, it depends on the used driver.

Just now I've find out that in my schematic I've used as output PB3, that is also the SPI MOSI. So we shall use PB1 (PB2 is used by the Ethernet Shield).

Regards,
Dario.

We can assume that not all relays are powered on at the same time... so there is a little statistical margin.

Use latching relays, that way there's no power being drawn normally.

That RS485 signal injecting requires Manchester encoding, although I gather you're not using 485 any more.

I think that the RS485 solution shall be discarded, just because all the available IC doesn't allow to read back the values that are on the bus.

What chip is that, AFAIK all RS-485 transceivers allow reading back of the output.

Sorry if this has been covered, I'm trying to catch up with this mega thread.


Rob

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.