The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
You are not going to be able to talk to the SRF01 from Netduino without the hardware break. I fired up Fritzing, made a schematic and connected the corresponding breadboard wires. The project is here, https://www.dropbox....NXj2cVZn8bAJjYa
I am pretty sure it's correct, but no guarantees. Starting from a schematic, ratsnest wires are transfered back to the breadboard and you need to connect them up with wires. Fritzing is a work-in-progress and I find it very limited and cumbersome to use. I use Eagle Cad for all of my work.
In any case, you need to develop the capability to transfer a schematic to a breadboard. Here is a nice online free application for electronic design work,
I'm looking at connecting a range finder through serial to the D1 TX port of my N+2, but in order to send a command to the device I first need to send a "break". Unfortunately, it appears that the NETMF SerialPort class doesn't support the "BreakState" property like the standard .NET Framework SerialPort class does.
Does anyone know how I might do the same thing using NETMF?
Notes collected on various forums for sending a break. It seems as though changing the UART to 1/2 or 1/4 of the actual line speed and then sending a single null byte will simulate a break. Sending breaks was in my distant past and I really never tested break sending.
NOTES (sorry no attribution available)
===========================
(1)---------------
A serial break is not a character. It is a signal that can be sent using the
TX line of the device sending the break.
When a serial port is idle and no data is being sent the TX line is in a
logical 1 state. While data is being send the TX line rapidly transitions
between logical 0 and logical 1. Each frame of data takes a certain period of
time to send, depending on the bit rate of the connection. This is called
the "frame time" or "word time".
A break occurs when the TX line is held to a logical 0 for longer than one frame time.
------------------ End (1)
(2)--------------- Microsoft (PC)
Method 1
The International Consultative Committee for Telephone and Telegraph (CCITT) modem
recommendations require a break signal to be at least "2m+3" bits long, where "m"
is the nominal number of bit times in an asynchronous character, usually 10; this
means that the minimum break time is 23 bits, with no maximum specified. Usually,
much more than the minimum is sent, such as 100 or 200 milliseconds
(that is, hundreds of bit times at high data rates). The timer resolution in a PC
is sufficient for sending such "long" BREAK signals, but not sufficient to send
exactly 23 bit times.
Method 2
An alternative means of sending a BREAK signal of shorter duration is to temporarily
change the data rate in the UART to half or 1/4 of the actual line speed and then send
a single NULL byte. This is more precise than using SetCommBreak() and ClearCommBreak(),
but it has the disadvantage of corrupting received data during the time the BREAK
signal is being sent (because the received data rate is wrong during that time).
An application can change the date rate in the UART with a call to SetCommState().
The DCB structure passed to SetCommState() specifies the new data rate.
------------------ End (2)
(3)---------------DS2480B
If break is not available on the host UART then switching to
a slower baud rate and sending a zero byte can simulate a break. Switching to
space parity or changing to a 9-bit word length with a zero in the most
significant bit can also simulate a break.
------------------ End (3)
(4)---------------
If sending, you need to disable the TX function of the USART, set the pin as
an output and hold it low for the break period, then re-enable the TX function,
and you can start sending data.
If receiving you don't have to do anything too special... A break will come as a
received character with a framing error, and a value of 0x00.
------------------ End (4)
(5)---------------
You can change uart's baudrate to lower value and send 0x00 byte.
(e.g. 0x00 byte transmitted with baud=57600 is break condition for baud=115200)
------------------ End (5)
Thank you very much for sharing your research with me. When the header wires that I've ordered arrive I will attempt to incorporate the information that you provided in a test project.
Unfortunately, this issue is literally a show stopper for me. If I'm not able to even address the sensor, then I won't be able to send it any commands either.
As noted in the comments/answers, the circuits need improvement, but they allow control of your break with a GPIO pin. The AND gate suggestion of the of the answer in link 1 looks to be the best and simplest approach,
Quote:
"What you really want is an ordinary AND gate. When both inputs are high, the output is high, but if either input goes low, then the output goes low"
I noticed on the second link that you sent through this up-voted response:
Unless your microcontroller has fixed-function special purpose pins, you would likely find it much easier to temporarily reconfigure the TX pin as a GPIO, drive it low for the desired period of time, then reconfigure it as the UART output.
As I'm only relatively new to the devices scene, does this mean that I could reference pin D1 as both a GPIO OutputPort and a SerialPort within the same code block? Would this make it possible to drive the OutputPort low (i.e. Write(false)) followed by sending commands to the SerialPort?
Frankly, I do not know if you can mess with the serial port parameters after you have instantiated it. Others may know. Re-reading the hardware on the TX line posts, I find the AND gate very appealing in its simplicity.
If I were trying to do this I would use the AND gate and;
(1) setup the serial port (COM1/D0,D1)
(2) configure a GPIO port as as an output port (say, D3)
(3) connect the GPIO port to input 2 of the AND gate , TX to input 1 and output to sensor RX
(4) in your sensor driver, include a BREAK command (default GPIO pin = high, must always be high outside of BREAK)
(5) in the BREAK command code,
( a ) set the GPIO output port low
( b ) send text to the sensor equivalent to the required BREAK time
( c ) set the GPIO output port high
( d ) exit break command
5.b will send zeros in place of the text character. You need to workout the number of characters to send.
Thanks for the excellent description! I'm going to purchase an AND gate now and see if I can get this thing working.
Is there any reason why you mentioned the 4 gate AND in your reply? Would this be for connecting multiple devices or for using multiple devices to generate the "break" state?
Following your previous instructions, I have attached a diagram of what I think the circuit might look like. When you get some time, could you review the image and see if you think the setup I have created is correct?
Here is the datasheet for the IC that I purchased:
Pin designations A and B are inputs and Y is output. The gates are grouped by 3 (A,B,Y) moving down from pin 1. You want 1A (pin 1) connected to TX and 1B (pin 2) connected to BREAK (or conversly, it doesn't matter). 1Y (pin 3) is the output of the gate connected to sensor RX. You need to move the white wire to 1Y (pin 3) next to the blue wire. Everything else looks ok.
I hope this works. It is a neat solution for a break thanks to Dave Tweed's answer on electronics.stackexchange.
Here is a Netduino post that might interest you, http://forums.netdui...mx-transmitter/
He is using the AND gate approach for the BREAK. Apparently it works because he has tested it.
Thanks for the reference. Actually, I saw this a few days ago but I didn't understand it until you explained the configuration in a couple of your previous posts.
I'm still waiting on my header wires to arrive, but hopefully I'll get to test the setup within the next few days.
My header wires arrived today so I was able to set up my Netduino Plus 2, range-finder (SRF01), and logical AND Gate exactly as my last diagram describes (with the help of Baxter). After nearly two hours of frustration the results are in:
1. Range-finder flashes on power up.
2. Debugging session begins ok.
3. Break command is sent to the sensor.
4. Two commands follow (the sensor address and the status command).
5. All bytes appear to be written.
6. No bytes are available to be read back (that's right, zero bytes).
According to the documentation, I should be receiving bytes back as representing a return value from the previously sent command. I get nothing. It's as if the break command isn't being sent at all and so the sensor isn't even aware that anything has happened.
I searched for the SRF01, http://www.robot-ele...m/srf01tech.htm
you have not picked an easy part to start your hardware adventures. The problem is you are sending out on Netduino TX to SRF01 RX and SRF01 is sending back on the same line, but you are listening on the Netduino RX which has no connection to the SRF01. Hook Netduino TX/RX with the diode as shown in this circuit from the reference and it will probably work. The site looks to be pretty complete for interfacing the SRF01.
I haven't picked an easy part to start my hardware adventures, you say? Well, you can say that again!!
I noticed the diagram that you attached a week or so ago but for some reason thought that it only applied to serial connections to a PC. I also noticed that some of the code I was attemping to translate from Arduino was referencing the RX/TX line together - as if it was one physical wire that could be engaged as either Receive or Transmit based upon a flag. This is obviously not the way Netduino works.
Looks like I need to get a BAT85 schottky diode. However, there are still a couple of questions that I'm not sure about:
a ) Does one leg of the diode need to connect to D0 and the other to D1 (i.e. RX/TX)?
b ) How does the RX line of the sensor connect to the diode if both legs are already plugged in?
I'm learning a lot while making all these mistakes, so I've appreciated your help immensely. If I can get this sucker working finally, I'm going to shout you a round of beer!
Arduino SoftSerial has the capability to setup serial pins (TX,Rx) or (TX,TX) for half-duplex as I remember. Looking at that diode circuit again. I don't think it will work. Their C# demo program is running on a PC with a software BREAK available and maybe the diode hooked up as shown is required by the program. This is what I don't understand; Quote: "A small schottky diode is used to prevent the SRF01 trying to drive the S22/S27's output line (data from the PC)." If this is true, it looks like they have the diode connected backwards.
From the web page analysis of the circuit (Read SRF01 for AVR), it looks like this should work. Make connections:
(1) Tx/Rx is the connection to the SRF01 I/O
(2) TX = Netduino TX
(3) RX = Netduino RX
So, in addition to your BAT85 purchase, buy a 2N3904 NPN transistor and a 10K resistor. You can then experiment with both circuits. It is quite possible that there is a property or setting lurking somewhere in the MF serial class to put the serial port into half-duplex mode. I haven't found it. In any case, you are doing useful work here.
P.S.
a ) Does one leg of the diode need to connect to D0 and the other to D1 (i.e. RX/TX)?
b ) How does the RX line of the sensor connect to the diode if both legs are already plugged in?
===
Bring D0/D1 out to a breadboard with jumper wires and build your circuit there. Diode connected between D0 and D1 on the breadboard then connect a jumper wire between the anode junction and the SRF01 input.
This stuff is going to haunt me, I know it... But thanks again for your help.
I managed to pick up a 2N3904 NPN transistor as well as a BAT 48 Shottky diode (they didn't have an 85 so it's on order).
I'll start with the diode attempt as per your suggestion from the spec page for the Atmega32. I have attached an image with the setup that I have created, but I'm not sure if it is accurate. I was hoping that you might be able to offer me some suggestions here.
At any rate, I know that this configuration will not allow me to reference serial COM1 on the Netduino if I'm also attempting to use either pin D0 or D1 to furnish the "break" command - an InvalidOperationException will be thrown due to a conflict on the pins. Consequently, I'm not sure how using just the diode solution will work with the Netduino. I think I understand how it would work on the Arduino or Atmega32 given that RX and TX can be referenced on the same pin, but such doesn't appear to be the case on the Netduino.
And so I'm back to where I started... Confused, bemused and abused.
I would step back to square zero on your project and then take small steps. First establish that you can communicate with the SRF01. Go to http://www.robot-ele...m/srf01tech.htm
and download the terminal program under heading, Testing (it compiles and runs just fine on my PC). Buy a FTDI based USB to serial adapter and plug it into your PC. The driver should install automatically; if it doesn't, then install the VCP drivers. Other chip based USB to serial adapters will work, but you may need to download drivers. Hookup the SRF01 as shown in the circuit under heading, Testing. You can get power from the adapter. The adapter and I/O to the SRF01 connections are: Diode cathode (band) connected to adapter TX, anode connected to SRF01 I/O and adapter RX. Just like your jpg picture hookup, but substitute the USB adapter connections in place of the Netduino connections. This should work because the PC serial class has a software BREAK. I would try it, but i do not have such a weird part as the SRF01. If you can't get a response then your SRF01 may be bad.
Now, you are ready to move on. I would port the code of the PC terminal program to run on Netduino. We know that the AND gate works for a BREAK so substitute the GPIO = low code here
I would also use the half-duplex circuit (call it Interface) then
Netduino RX(D0) ---------------- RX (Interface) --- SRF01(I/O)
Netduino TX(D1) --- AND gate --- TX(Interface) --- SRF01(I/O)
Netduino GPIO(D4) --- AND gate
The output of Interface is a single line connected to SRF01
Just so you know, I have multiple SRF01’s available to use and have tested with more than just one. Unless I received a bad batch, then they all seem to be working the same way (power flash appropriate to the tech specifications). Additionally, the code that you referenced is the code that I have actually been working with since the beginning – I’ve only been consulting the Arduino code as a secondary verification.
I’ve attached another image showing what I think you were saying about connecting a serial port to a diode. Please let me know if I’ve misunderstood you. Once I have the serial adapter, I’ll test out this configuration along with any further suggestions you have.
Answered
