next topic »

[Reply #45 on:]

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.

[Reply #46 on:]

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.

[Reply #47 on:]

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.

[Reply #48 on:]

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

[Reply #49 on:]

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

[Reply #50 on:]

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.

[Reply #51 on:]

Does you have suggestion?

What you are currently doing is a bit analogue for me

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

[Reply #52 on:]

What you are currently doing is a bit analogue for me

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.

[Reply #53 on:]

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.

[Reply #54 on:]

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.

[Reply #55 on:]

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.

[Reply #56 on:]

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

[Reply #57 on:]

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!

[Reply #58 on:]

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.

[Reply #59 on:]

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: https://github.com/ethermania/FSKonDCbus. 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