There are no resistors in series with the wires, only 10K pull-ups on Port2 rx and rx lines. Port 2 is where I have the problems, its got to be something in the code that is wrong
I can't imagine a way the code can make the 3.3V droop to 2.02V... assuming I understand your descriptions
of scope screen... Sounds more like some pull-downs on each module - and strong ones at that.
Your scope shows a loading effect.
Take a multimeter on 200 mA range, and connect to pull down the RX line(s) thru the meter for one and two connected boards. A 10k resistor alone will measure 330uA per load.
I couldn’t get a good current reading with my Fluke so I checked the voltage drop across the 10K resistor on the pin2 (RX) side of the leg controllers. With 1 leg controller connected it read 1.389v across it. When I connected the 2nd leg the voltage drop increased to 2.48v,which is inline with the earlier scope readings showing the signal getting greatly attenuated with 2 connections. I added a 3rd leg and the voltage drop went to 2.77v.
I checked the wiring harness and got 0.4 ohms from one end to the other on both the Tx and RX lines and no evidence that they are shorting together either. I also validated that the 10K resistors are at 9.88K and 9.9K also.
I can't imagine a way the code can make the 3.3V droop to 2.02V... assuming I understand your descriptions
of scope screen... Sounds more like some pull-downs on each module - and strong ones at that.
The leg computers are RoboPi boards so I checked the RoboPi schematic and according to it the location that I am plugging into connects directly to the prop pin. There is another connection on each pin that has a 2.4K resistor for inline protection with each pin but I am not using that connection so that shouldn’t be the issue. I did measure the voltage drop across the inline resistor connected to the RX pin and it showed 0.0v as expected.
The master computer is a Parallax propellor Activity board and its schematic shows the connections to pins 8,9, 10 are also direct connections to the prop. The only thing that can load the circuit down has to be the prop itself which leads me to think I have a code issue, either in my code or possibly the 4port serial object. Someone thought that the 4 port might not support an open collector so I coded the leg TX port (pin3) to be an input unless it gets a valid request on
RX (pin2). In theory only the computer that has a valid request from the master is transmitting with everyone else configured as an input.
I couldn’t get a good current reading with my Fluke so I checked the voltage drop across the 10K resistor on the pin2 (RX) side of the leg controllers. With 1 leg controller connected it read 1.389v across it. When I connected the 2nd leg the voltage drop increased to 2.48v,which is inline with the earlier scope readings showing the signal getting greatly attenuated with 2 connections. I added a 3rd leg and the voltage drop went to 2.77v.
Where does that 10k connect, and do you have one every slave, or is that one on master only ?
Are these board properly powered - do they have 3v3 verified ?
If the 10k is on master only, to 3v3, those numbers indicate a variable pull down, (not quite linear per slave either) Starts at 13.7k pulldown, then 3.3k then 1.9k
With more than 1 attached, you have lost a Logic 1 idle, so that explains why they cease to work. Something is draining 139uA, 248uA, 277uA
Even 1 is only just working.
Where does that 10k connect, and do you have one every slave, or is that one on master only ?
Are these board properly powered - do they have 3v3 verified ?
If the 10k is on master only, to 3v3, those numbers indicate a variable pull down, (not quite linear per slave either) Starts at 13.7k pulldown, then 3.3k then 1.9k
With more than 1 attached, you have lost a Logic 1 idle, so that explains why they cease to work. Something is draining 139uA, 248uA, 277uA
Even 1 is only just working.
The 10K resistors are located on the master (using the breadboard on the Activity board) and connect to the 3.3v positive side there. All the RoboPi boards are powered via a 5v input coming from a 12v to 5v DC-DC converter. No drop in input power showing with all boards powered. The converter is a high quality converter with very good noise immunity even with all the motors that are running on the 12v bus, almost no ripple in the 5v output. I don’t remember the current specs for the converter but it was well over-sized for the expected loads.
I looked more closely at the 4port object and there is a mode bit 2 for open-drain/source tx that I set on the leg computers, no change in symptoms. I also slowed the port speed down to 9600 baud to see if that made a difference.
I put in some more debugging code in the leg computer to monitor what the leg#3 is seeing when I connect leg#4 up. Monitoring leg#3 on the monitor, the combuffer shows ‘$,1’, then ‘$,2”, then ‘$,3’ coming in from the master on pin2. At that time leg#3 outputs on pin3 the status, ‘$,1,1,1,1’. Then it goes on showing requests for leg 4, 5, and 6 before starting the cycle again. This is the expected behavior.
Just as soon as I add the master transmit connection to Leg#4 pin 2, the monitor just stops scrolling and at that point appears to be waiting for an input. Removing the wire from pin 2 on Leg#4 restores proper operation.
I put in a totally different wire from the master to leg#3 and Leg#4, exact same symptoms. I changed the output pin on the master from pin 9 to pin 15, no change in operation.
Of course just to confuse things, I’m been successfully using port 1 to transmitt from the master to the legs also over master pin 11 to leg pin 1. The only difference is that rx pin (10) on the master for port1 isn’t connected since this is to just get leg commands out to the legs. But here there is no issue with loading down the bus with all 6 slaves - I don’t have any protection resistors or pull-ups on this wire either.
... then ‘$,2”, then ‘$,3’ coming in from the master on pin2. At that time leg#3 outputs on pin3 the status, ‘$,1,1,1,1’. Then it goes on showing requests for leg 4, 5, and 6 before starting the cycle again. This is the expected behavior.
Just as soon as I add the master transmit connection to Leg#4 pin 2, the monitor just stops scrolling and at that point appears to be waiting for an input. ..
Something on your boards is clearly loading the RX lines.
An easy thing to try, since the load seems more modest, is to lower the master 10K pullup, to as low as 330 ohms.
The master now needs to sink 10mA, which it should be able to do (to < 1V) , and now you should be able to add more than 2 slaves, before it stops working.
Measure the drop across the 330R, as you add more slaves.
Something on your boards is clearly loading the RX lines.
An easy thing to try, since the load seems more modest, is to lower the master 10K pullup, to as low as 330 ohms.
The master now needs to sink 10mA, which it should be able to do (to < 1V) , and now you should be able to add more than 2 slaves, before it stops working.
Measure the drop across the 330R, as you add more slaves.
The smallest resistor I have is a 1K so I tried it and got 1.5v across it with a single slave, voltage went to 2.5 with a second slave. Watching the scope signal at the resistor went from 2.08Vpp to 1.08Vpp.
* Changed the master Tx pin to see if that made a difference but there is no change in operation or values.
* Changed the serial object from pcFullDuplexSerial4FC to FullDuplexSerial4Port with no change in behavior.
* Tried using a different slave (leg#5) with the same results.
The only things that are common to everything is the wiring harness (which I changed out to another wire and got the same results), the RoboPi board design (according to the schematic I am connecting directly to the prop pin with no resistance between the wire and pin), the software used on each RoboPi board is identical for the serial interface portion (this seems to be the most logical location for a software error somehow causing the slave Rx port to get loaded down), and lastly the Master computer. I don’t have another one of the master computer boards to change out but I tried using another Tx port in case that was an issue with no difference in operation.
Another thing that gets me going is something I mentioned before, I already have port2 on the master transmitting on pin 11 to all the legs which are listening on their port1 (pin1) and that works just fine. Software wise the code is the same, there is just no slave to master transmission on that port.
I don’t know if I had tried this before but when I removed the master to slave transmission wire the signal is 3.3vpp on the o-scope. Adding one slave drops the Vpp to 2.08, a 2nd slave connection takes it to 1.0-1.16Vpp. That leads me to believe the problem is located in the RoboPi board or its software setup. I’m going to try some other tests and see what happens.
I couldn’t get a good current reading with my Fluke so I checked the voltage drop across the 10K resistor on the pin2 (RX) side of the leg controllers. With 1 leg controller connected it read 1.389v across it. When I connected the 2nd leg the voltage drop increased to 2.48v,which is inline with the earlier scope readings showing the signal getting greatly attenuated with 2 connections. I added a 3rd leg and the voltage drop went to 2.77
....
The smallest resistor I have is a 1K so I tried it and got 1.5v across it with a single slave, voltage went to 2.5 with a second slave. Watching the scope signal at the resistor went from 2.08Vpp to 1.08Vpp.
and 3 slaves ? If you have more than one 1k, you could parallel them.
Strange - the reported drops are close to the same for 1k as 10k, and so behave more like a clamp than a load, but how can any clamp know you have connected another slave, and shift the clamping value.. ?
Can you post a scope shot for 1/2/3 slave loading replies, at a modest baud rate ?
You could get the slave to output a square wave on any spare pin, to confirm VCC and GND integrity, right thru to the die. ie confirm those really are 3.3V and 0.0V
At this point I think the problem has been identified but not what is causing it and that is becoming very elusive. I’m going to try another approach to getting the slave information back to the master since there is always more than one solution to a problem. It’s been a week of frustration but lots of help from the group, I was sure we would have found the issue quickly and the solution but this is a tough one. Since I have master IO available, I’m going to add a 2nd 4 port serial port and dedicate one port for each slave. This way there is only one way traffic, no data collision issues either. The only networked wire to the slaves will be the one that is working right now and it handles movement commands.
Thank you everyone for their suggestions and comments.
I still would recommend to think about Beaus Method. You might need to rethink the whole protocol to do so.
Basically each Propeller needs two pins for one fullduplex serial. Now you daisy chain them, output of one goes to input of the other until you have a full circle.
So the master can send a string/buffer and then wait for it to return after passing thru all Propeller.
Each leg reads the serial string into a buffer, adds its own comments/return values and read its commands. Then it sends the buffer to the next Propeller.
In the buffer you just define a structure say each Leg has 5 or 10 longs to read or write to, first leg the first 10 longs, second leg the second 10 longs, one block for each leg.
So you send 60 longs around and around. Each propeller has a 60 long Buffer, reads the buffer, copies his next command, writes his last results into his part of the buffer and sends it along.
When the master receives the buffer it has all data there can work on it set new command values and sends the buffer on the next round.
Sure there is a delay on each leg until the buffer reaches the last leg, but when sending say 10 longs per leg we are talking about reading 60 longs at 115200 + time to copy command + time to write last result into buffer and send buffer. That can go around quite fast.
and in case of a breakdown of one propeller the whole system stops because communication is interrupted.
Might be good or bad, but the Master will know it because he receives no response.
it would need one full duplex serial per leg - you have that, check
it would need one port of 4port serial on the master - you have that, check
you would need to connect the master to one leg, each leg to the other leg and back to the master. simple. one wire from pin to pin, no conflicts, always output to input.
Basically it works like with mailboxes in one propeller, you read and write the mailbox. but then you send the mailbox to the other propeller(s) and they have the values.
I remember reading about Beau’s setup a while ago when I was figuring out the communications options. I thought that it required 2 cogs to operate, at least on the master, which I did not have available. Am I remembering it right or is it only a single cog per node?
I started some simple changes to the communications like I stated earlier, instead of a ring network, I’m setting up a star configuration. I want to give that a go and see how well it works. At least I feel like I’m moving forward with a purpose again...
Well, yes @"Beau Schwabe" used 2 cogs per propeller, but you don't need too, a single COG with full duplex serial has one RX and one TX.
But basically it does not matter if two COGs or one. Beau just wanted something like 12 Mbit transfer between propellers, thus two COGs.
The same 'protocol' for transferring mailboxes will work with 9600 baud or 115200 baud also. It does not depend on speed so much, since you would just circulate a small amount of data.
The trick is the timing. Receive the buffer, copy command/parameter (if there) somewhere else in Hub, copy last commands result or current position values into the buffer, transfer the buffer and then execute the new command.
When sending say 60 longs around or even 120 everything will fit in the buffer of transmitting and receiving Fullduplex serial so even when executing the command takes a bit longer the receiving buffer buffers it until needed.
Same goes for the TX buffer, you fill the buffer and then you have time to execute the command while FDS will send the buffer out to the next Propeller's FDS RX.
On the master you could still use one of 4-port serials ports. Since the real transfer between FDS on one prop and FDS on the next prop runs from buffer to buffer in the background the actual transfer speed is not really important.
I used this successful in some projects and if you think about it a while you should see it as a slightly delayed Mailbox as if the routines on the leg controllers would have their mailbox in the master controller.
For the cost of two pins and one COG you can add 7 more COGs per leg to the master controller.
Once set up it is very flexible, each Leg needs to know its position in the buffer and the total size, has then a block of longs to read from and write to, before sending it along.
So if you need to send more data around just resize the buffer and give the legs a new starting position inside of the buffer.
I see what you mean, use the concept that Beau came up with but use the serial terminal to implement it. Took me a while to figure out that’s what you were advocating. Let me try out the star network configuration since I’ve already wired that in and started coding for it. If that doesn’t give me the results I need then I’ll give this a concept a try.
Just wanted to say thank you for sticking with me to try and figure out a fix, I really appreciate the time and effort you gave towards my issue!
Comments
I can't imagine a way the code can make the 3.3V droop to 2.02V... assuming I understand your descriptions
of scope screen... Sounds more like some pull-downs on each module - and strong ones at that.
I checked the wiring harness and got 0.4 ohms from one end to the other on both the Tx and RX lines and no evidence that they are shorting together either. I also validated that the 10K resistors are at 9.88K and 9.9K also.
The master computer is a Parallax propellor Activity board and its schematic shows the connections to pins 8,9, 10 are also direct connections to the prop. The only thing that can load the circuit down has to be the prop itself which leads me to think I have a code issue, either in my code or possibly the 4port serial object. Someone thought that the 4 port might not support an open collector so I coded the leg TX port (pin3) to be an input unless it gets a valid request on
RX (pin2). In theory only the computer that has a valid request from the master is transmitting with everyone else configured as an input.
Are these board properly powered - do they have 3v3 verified ?
If the 10k is on master only, to 3v3, those numbers indicate a variable pull down, (not quite linear per slave either) Starts at 13.7k pulldown, then 3.3k then 1.9k
With more than 1 attached, you have lost a Logic 1 idle, so that explains why they cease to work. Something is draining 139uA, 248uA, 277uA
Even 1 is only just working.
I looked more closely at the 4port object and there is a mode bit 2 for open-drain/source tx that I set on the leg computers, no change in symptoms. I also slowed the port speed down to 9600 baud to see if that made a difference.
I put in some more debugging code in the leg computer to monitor what the leg#3 is seeing when I connect leg#4 up. Monitoring leg#3 on the monitor, the combuffer shows ‘$,1’, then ‘$,2”, then ‘$,3’ coming in from the master on pin2. At that time leg#3 outputs on pin3 the status, ‘$,1,1,1,1’. Then it goes on showing requests for leg 4, 5, and 6 before starting the cycle again. This is the expected behavior.
Just as soon as I add the master transmit connection to Leg#4 pin 2, the monitor just stops scrolling and at that point appears to be waiting for an input. Removing the wire from pin 2 on Leg#4 restores proper operation.
I put in a totally different wire from the master to leg#3 and Leg#4, exact same symptoms. I changed the output pin on the master from pin 9 to pin 15, no change in operation.
Of course just to confuse things, I’m been successfully using port 1 to transmitt from the master to the legs also over master pin 11 to leg pin 1. The only difference is that rx pin (10) on the master for port1 isn’t connected since this is to just get leg commands out to the legs. But here there is no issue with loading down the bus with all 6 slaves - I don’t have any protection resistors or pull-ups on this wire either.
An easy thing to try, since the load seems more modest, is to lower the master 10K pullup, to as low as 330 ohms.
The master now needs to sink 10mA, which it should be able to do (to < 1V) , and now you should be able to add more than 2 slaves, before it stops working.
Measure the drop across the 330R, as you add more slaves.
* Changed the master Tx pin to see if that made a difference but there is no change in operation or values.
* Changed the serial object from pcFullDuplexSerial4FC to FullDuplexSerial4Port with no change in behavior.
* Tried using a different slave (leg#5) with the same results.
The only things that are common to everything is the wiring harness (which I changed out to another wire and got the same results), the RoboPi board design (according to the schematic I am connecting directly to the prop pin with no resistance between the wire and pin), the software used on each RoboPi board is identical for the serial interface portion (this seems to be the most logical location for a software error somehow causing the slave Rx port to get loaded down), and lastly the Master computer. I don’t have another one of the master computer boards to change out but I tried using another Tx port in case that was an issue with no difference in operation.
Another thing that gets me going is something I mentioned before, I already have port2 on the master transmitting on pin 11 to all the legs which are listening on their port1 (pin1) and that works just fine. Software wise the code is the same, there is just no slave to master transmission on that port.
connector pin to ground and to Vcc?
Strange - the reported drops are close to the same for 1k as 10k, and so behave more like a clamp than a load, but how can any clamp know you have connected another slave, and shift the clamping value.. ?
Can you post a scope shot for 1/2/3 slave loading replies, at a modest baud rate ?
You could get the slave to output a square wave on any spare pin, to confirm VCC and GND integrity, right thru to the die. ie confirm those really are 3.3V and 0.0V
Thank you everyone for their suggestions and comments.
Basically each Propeller needs two pins for one fullduplex serial. Now you daisy chain them, output of one goes to input of the other until you have a full circle.
So the master can send a string/buffer and then wait for it to return after passing thru all Propeller.
Each leg reads the serial string into a buffer, adds its own comments/return values and read its commands. Then it sends the buffer to the next Propeller.
In the buffer you just define a structure say each Leg has 5 or 10 longs to read or write to, first leg the first 10 longs, second leg the second 10 longs, one block for each leg.
So you send 60 longs around and around. Each propeller has a 60 long Buffer, reads the buffer, copies his next command, writes his last results into his part of the buffer and sends it along.
When the master receives the buffer it has all data there can work on it set new command values and sends the buffer on the next round.
Sure there is a delay on each leg until the buffer reaches the last leg, but when sending say 10 longs per leg we are talking about reading 60 longs at 115200 + time to copy command + time to write last result into buffer and send buffer. That can go around quite fast.
and in case of a breakdown of one propeller the whole system stops because communication is interrupted.
Might be good or bad, but the Master will know it because he receives no response.
it would need one full duplex serial per leg - you have that, check
it would need one port of 4port serial on the master - you have that, check
you would need to connect the master to one leg, each leg to the other leg and back to the master. simple. one wire from pin to pin, no conflicts, always output to input.
Basically it works like with mailboxes in one propeller, you read and write the mailbox. but then you send the mailbox to the other propeller(s) and they have the values.
Enjoy!
Mike
I started some simple changes to the communications like I stated earlier, instead of a ring network, I’m setting up a star configuration. I want to give that a go and see how well it works. At least I feel like I’m moving forward with a purpose again...
But basically it does not matter if two COGs or one. Beau just wanted something like 12 Mbit transfer between propellers, thus two COGs.
The same 'protocol' for transferring mailboxes will work with 9600 baud or 115200 baud also. It does not depend on speed so much, since you would just circulate a small amount of data.
The trick is the timing. Receive the buffer, copy command/parameter (if there) somewhere else in Hub, copy last commands result or current position values into the buffer, transfer the buffer and then execute the new command.
When sending say 60 longs around or even 120 everything will fit in the buffer of transmitting and receiving Fullduplex serial so even when executing the command takes a bit longer the receiving buffer buffers it until needed.
Same goes for the TX buffer, you fill the buffer and then you have time to execute the command while FDS will send the buffer out to the next Propeller's FDS RX.
On the master you could still use one of 4-port serials ports. Since the real transfer between FDS on one prop and FDS on the next prop runs from buffer to buffer in the background the actual transfer speed is not really important.
I used this successful in some projects and if you think about it a while you should see it as a slightly delayed Mailbox as if the routines on the leg controllers would have their mailbox in the master controller.
For the cost of two pins and one COG you can add 7 more COGs per leg to the master controller.
Once set up it is very flexible, each Leg needs to know its position in the buffer and the total size, has then a block of longs to read from and write to, before sending it along.
So if you need to send more data around just resize the buffer and give the legs a new starting position inside of the buffer.
I found it very reliable and easy to use.
Enjoy!
Mike
Just wanted to say thank you for sticking with me to try and figure out a fix, I really appreciate the time and effort you gave towards my issue!
Enjoy!
Mike