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.

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.

AND gate parts:
1 gate AND: 74LVC1G08
4 gate AND: 74HC08

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.

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,

http://easyeda.com/

Your connections are now correct ...

Wrong cable ... The one you linked is USB to RS232. I should have been more explicit. What you want is is USB to TTL. Something like this,
(1) http://www.ebay.com/...e-/261101529602
or this,
(2) http://www.mouser.co...j627GFcejHp0Q==
or this,
(3) http://yourduino.com...ct_detail&p=164

With the first two, you can plug your jumper wires into the end of the cable and then into the breadboard to bring the signal lines to the breadboard for connections. The third style can plug directly into the breadboard, but be careful that the header pins have enough depth and are not too far offset from the edge of the PCB. Most of my USB to serial TTL are like number (3). The RS232 version you ordered is not of much use for Netduino work. I would cancel your order if you can. The RS232 cable can be used for download with the Netduino Mini.

Serial RS232 and TTL are different protocols that are characterized by the logic state voltage. If you measure voltage with no transmission on a TTL TX line, it will be 5V corresponding a logic 1. For RS232, logic 1 will measure at about 2.7V or less. In most cases, USB to RS232 adapters do not conform to the RS232 standard. A further characterization is; TTL idles high and RS232 low..

Comment on Fritzing layout
==========================
Last post: Remove the blue wire. Netduino RX doesn't have anything to do with the BREAK.
Next to last post: Correct, but lose the RS232 adapter. See above comments. If you use it, you will need to add add a chip to invert TX and RX from/to the adapter.

I will try to dredge up my lost knowledge of Fritzing and try my hand at layout of the breadboard. This is turning into an intriguing problem.

I forgot to include two references to do a break with some hardware on the TX line,

http://electronics.s...emitter-followe
http://electronics.s...me-periods?lq=1

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"

So,
gate input 1: TX, input 2: GPIO = high ---> gate out: TX = regular transmission
gate input 1: TX, input 2: GPIO = low  ---> gate out: TX = low/break (hold GPIO low for break time)

I don't know if this gives a genuine break, but it is worth a try.

Remove the red power to the diode.

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

 private void SendBreak()
        {
            SerPort.BreakState = true; 
            Thread.Sleep(2);
            SerPort.BreakState = false;
        }

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

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. 

Here is a circuit for a single pin software UART,

http://nerdralph.blo...tware-uart.html
and the driver,
https://sites.google...asicSerial3.zip

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.

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)

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.

Completely missed this reference ...

Assuming that the Netduino is part of some circuit, maybe you could use a 1-wire unique serial number,

http://www.maximinte...cts/DS2411.html

RETROSPARK promotional code doesn't work on this item. I just tried to buy it. The price is $50.

I don't think the Spark Core is Micro Framework compatible. You may have a bit of trouble connecting the hardware to a Netduino Plus 2. Maybe you could talk to it over the serial interface. Or perhaps, give your Netduino a wireless interface with an ethernet to wireless adapter ,

http://forums.netdui...-a-pc-wireless/

I bought a Spark Core and it looks to be a nice companion to provide WiFi capability for a Mini or a Netduino 1 or 2 by talking over the serial port as EnergySmithe noted. There are two serial ports, serial and serial1. The former is the regular Arduino debug port to be used with a serial terminal and the latter would be used to talk to a Netduino. The IDE is cloud based with the same buttons as the Arduino IDE, verify, flash ... They also have an Android App to work with the pins and configure the core for your network. I found the following sample code for a webserver and it works like a charm. The only problem I see with it vs Netduino is shifting gears to program an Arduino.

TCPClient webClient;
TCPServer webServer = TCPServer(80);
char myIpAddress[24];
int LED = D7;

void setup() {
    pinMode(D7,OUTPUT);         // Turn on the D7 led so we know it's time
    digitalWrite(D7,HIGH);      // to open the Serial Terminal.
    
    Serial.begin(9600);

  // Now it's ok to open your serial terminal software, and connect to the
  // available COM port.  The following line effectively pauses your
  // application waiting for a character to be received from the serial
  // terminal.  While it's waiting it processes the background tasks to
  // keep your Core connected to the Cloud.  Press ENTER in your 
  // serial terminal to start your application.
  while(!Serial.available()) SPARK_WLAN_Loop();
  
    Spark.variable("ipAddress", myIpAddress, STRING);
    IPAddress myIp = Network.localIP();
    sprintf(myIpAddress, "%d.%d.%d.%d", myIp[0], myIp[1], myIp[2], myIp[3]);
    
    Serial.print("Spark Core connected to IP: ");
    Serial.println(myIp);
    digitalWrite(D7,LOW); // Turn off the D7 led ... your serial is serializing!
    
    webServer.begin();
}

void loop() {
    if (webClient.connected() && webClient.available()) {
        serveWebpage();
    }
    else {
        webClient = webServer.available();
    }
}

void serveWebpage() {
    //TODO: read in the request to see what page they want:
    //TODO: retrieve larger content from flash?

    webClient.println("<html>Hello I'm serving a webpage!</html>\n\n");
    webClient.flush();
    webClient.stop();
    delay(100);
}

Thanks ... Great price, bought one.

I just bought a discounted Seeed Gprs at Radio Sack,
http://www.seeedstud...erface_Function
I now find that Seeed is selling a new model, but the basic functionality is the same as the old one.

The serial setup is different from yours, but I think they are doing the same thing. I have mine with the jumpers set to hardware. The shield is plugged in to the Netduino and Netduino is directly talking to the module via COM1. If you want to talk to the module from a PC terminal, configure yours for hardware, but don't plug it in to the Netduino.and take power externally. Then connect a USB-TTL cable to D0, D1 on the shield. The USB to RS232 cable you linked is wrong for this application.  You might look at these depending upon the versatility you want ( you can get a cheaper USB to TTL  adapter on ebay),

https://www.sparkfun.../products/12977

https://www.sparkfun.../products/11736

My driver in VB seems to working ok with simple commands,

        SeeedGprs.SendReceiveCmd("AT") 'can communicate
        Debug.Print("CmdSent: " & SeeedGprs.CmdSent)
        Debug.Print("CmdAnswer: " & SeeedGprs.CmdResponse)
        Thread.Sleep(400)
        SeeedGprs.SendReceiveCmd("AT+COPS?", , 400) 'Carrier info
        Debug.Print("CmdSent: " & SeeedGprs.CmdSent)
        Debug.Print("CmdAnswer: " & SeeedGprs.CmdResponse)
        Thread.Sleep(400)
        SeeedGprs.SendReceiveCmd("AT(+CSQ)") 'signal quality
        Debug.Print("CmdSent: " & SeeedGprs.CmdSent)
        Debug.Print("CmdAnswer: " & SeeedGprs.CmdResponse)


CmdSent: AT
CmdAnswer:  OK 
CmdSent: AT+COPS?
CmdAnswer: PS: 0,0,"T-Mobile"  OK 
CmdSent: AT(+CSQ)
CmdAnswer: OR 
 

To go much further, I need an activated SIM card. The phones I have use a micro SIM and these modules take a standard size. I guess the answer is to just use the carrier for a micro SIM in in an activation kit.

Not VS 2013, but Using C# 2010 Express, MF4.2 and pushing the button on a Plus 2, yields nearly instantaneous debug output and led blink.

--> Button interrupt caught.

This has been frustrating for me also. Maybe it is both an IE11 and a Forum problem. If I login with Chrome, pasting this this message from Notepad into a  Reply box works just fine.

Have you looked at this for multiple devices on the I2C bus?
http://forums.netdui...e-i2cbus-class/

What about DynDNS,
http://dyn.com/support/wizard/

http://www.tp-link.u...icle/?faqid=297
I haven't used it for a while, but I set it up for a Netduino Plus 1. It's fiddly to get going from behind your router unless you have a smartphone (or use a neighbor's network). Most consumer routers do not have NAT loopback so testing needs to be done from a network external to your local network. Or, in my case, I used a spare router running DD-WRT with NAT loopback for local testing. DynDNS is no longer free, but there are other services.

I don't see that this poses a greater security risk than other traffic coming in through your ISP.

Yes, there is a reason. When the light shines just right you can see the surface roughness. The Da Vinci business model has also received a lot of criticism for the chipped, proprietary filament cartridge. I wish I could afford a Form1 printer. The Da Vinci is cheap enough to play with, but I think I would be disappointed with its results. Thanks for the information about your service.

As someone obviously familiar with 3D printing, what do you think of the Da Vinci 1.0 3D Printer?

http://www.amazon.co...bs_6066127011_1

I really think the key to getting these pocket routers to work is to assign fixed, but different IP addresses (outside of the main router DHCP range) and disable DHCP on both. The other important ingredient is to let the Edimax establish itself on the network before connecting the Netduino. Ping it and make certain it is in the ARP table. I also find that it works equally well with a network configured Plus 1 or Plus 2.

rickggaribay, sorry for the problems. Networking can be frustrating at times. I googled for the Vonets and it seems that there are problems in setting it up. The fact that it needs software for setup and is using WinPCap means that this is totally different from the Edimax approach which requires no installation software.

I just hooked up an Edimax that is established on my network with an IP address of 192.168.0.4 to a Netduino Plus 2 that is not running any network related code. I then went to MFdeploy and set the Plus 2 network parameters:
Static IP address: 192.168.0.50
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.0.1
MAC Address: 5c-86-4a-00-50-0f
DNS Primary Address: 8.8.8.8
DNS Primary Address: 8.8.4.4
DHCP: unchecked

The router has a DHCP range of 100-200. I then opened a command prompt and pinged 192.168.0.50 followed by arp -a with the result:

Pinging 192.168.0.50 with 32 bytes of data:
Reply from 192.168.0.50: bytes=32 time=45ms TTL=255
Reply from 192.168.0.50: bytes=32 time=2ms TTL=255
Reply from 192.168.0.50: bytes=32 time=2ms TTL=255
Reply from 192.168.0.50: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.0.50:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 45ms, Average = 12ms

C:\Users\beb\Desktop>arp -a

Interface: 192.168.0.175 --- 0xb <--- desktop PC hardwired ethernet
  Internet Address      Physical Address      Type
  192.168.0.1           98-fc-11-6e-6a-40     dynamic
  192.168.0.4           80-1f-02-19-25-98     dynamic <--- Edimax
  192.168.0.50          80-1f-02-19-25-98     dynamic <--- Netduino Plus 2
  192.168.0.104         98-4b-e1-55-78-d6     dynamic
  192.168.0.113         80-1f-02-9d-b4-ec     dynamic
  192.168.0.117         f4-ce-46-4d-22-bc     dynamic

Notice the physical (MAC) address of the Netduino; it has now taken the MAC of the Edimax. I have no idea how this happens. But I think that the effect is that when you address the Netduino by its IP, it is actually being resolved to the Edimax which passes the traffic through to the Netduino. Although not certain, I believe that all of these ethernet to wireless adapters work the same way. I would suggest that you re-setup your Netduino network parameters with MFdeploy and make certain you are on the same subnet of your network. When I was searching for Vonets, I did notice that the latest software was important to get the adapter working.