chevi99,

I am in the middle of moving, so it will take me a bit to find the code.  However, the main issue turned out to be that I had wired the RS-232 to TTL converter incorrectly (see above).  You can't just connect the Netduino directly to the sonar for serial data transfer.

For the serial port, I had the problem mostly solved by just reading 5 bytes and discarding them if it didn't read correctly, but then my Create developed a problem sending serial data, so I switched to the sonar analog output--I haven't had a chance to get back to the serial transfer yet.  Important to remember that the Netduino analog input will NOT tolerate 5V--you have to use 3.3V.

--John Mc

I do get the banner.  Also found my 3.3v power supply.  Before I remembered that the power supply ground and serial Rx both needed to be common, the board went a little crazy and showed every symbol in the book all across both lines, but that suggests the display is capable of displaying the symbols.  I also noticed it isn't exactly two vertical lines--the rightmost line has one extra pixel sticking out of the right side.

Figuring I could've garbled the baud rate, I sent the 9600 baud reset (124 then r) during the splash screen display, but still no luck.

I'll ask at Sparkfun, too.  They might be able to identify if this is symptomatic of something.

This is the 3.3 volt board.  9600, 8, None, and 1.  The only connections are power, ground, and D3 out of the Netduino (Com 2 Tx) to Rx on the LCD.  Seems like it couldn't be any simpler...

public static SerialPort serialLCD = new SerialPort(SerialPorts.COM2, 9600, Parity.None, 8, StopBits.One);

I was wondering about the power since the spec sheet says the board wants 60mA with the backlight on, and the Netduino pins are rated for 25mA.  Looking at others' comments on this LCD board, though, I haven't seen any reference to using external power, and the backlight seems quite bright.

I'll start with the caveat that I'm still a novice at this, and am hoping someone will immediately know what I'm doing wrong based on the symptoms.

I have a Netduino Plus 2, firmware 4.2.2, and am attempting to send data to a 3.3v SerLCD LCD-09067, a 16x2 LCD.  I'm using Visual C# 2010.  When I send data, all I get is a set of parallel vertical lines in the first cursor position of the first line.

From the SerLCD datasheet, I've tried using the 254 commands to reposition the cursor and 124 commands to turn off the backlight--neither works.  Tried using both decimal and hex.  I've looked all over the forum without luck--it seems this should be really simple.

I've also tried keeping the board unpowered during Netduino boot, to avoid garbage characters being sent.  Still no luck.

The one thing that's occurred to me--does the Netduino 3.3v pin have enough power for the SerLCD board?  (I can't find my 3 volt battery pack at the moment, or would have tested this.)

After the program exits, if I leave everything turned on, after a couple minutes, additional vertical lines appear in the next cursor positions (6 more, at the moment).  Not sure if that's helpful or just spurious.

Thanks in advance for any help.

--John Mc

It took a little longer to get back to this than I'd anticipated...it seems the problem was Netduino versus NetduinoPlus using directive and reference.

Grabbed my old PC and completely rebuilt it from a bare hard drive to WinXP SP3 and Visual Studio C# 2010 with the MicroFramework 4.2, the Netduino 4.2.2 SDK.  (The bad news here is that my Win7 disc has gone missing, but that's a different problem...)  Created a NEW NetduinoPlus2 application, and was able to make the LED blink consistently.

Then copied the code over from the larger "problem" project into the new project; again the board worked.

Next, loaded the entire problem project copied over from my main computer; it immediately locked up the board.  Tried this 3 times to be sure I wasn't doing something different each time.  By "locked up" I mean that it won't even answer an MFDeploy ping.  (I'm also becoming quite proficient at erasing and flashing the firmware...)

I finally noticed that the new NetduinoPlus2 application actually adds "using SecretLabs.NETMF.Hardware.Netduino;" NOT "NetduinoPlus."  Tried changing out both directives and references--with just a Blinky routine, either one works.  With something more complicated, using NetduinoPlus and its reference locks the board immediately; the only solution seems to be reflashing.

Ultimately, this seems odd, since it's a Netduino 2 Plus, not a Netduino 2.  Does it make sense to you?

The project that fails has the following using directives:

System;

System.Net;

System.Net.Sockets;

System.Net.Threading;

Microsoft.SPOT;

Microsoft.SPOT.Hardware;

SecretLabs.NETMF.Hardware;

SecretLabs.NETMF.Hardware.Netduino (or NetduinoPlus);

System.IO.Ports;

System.Collections;

The next logical step seemed to be figuring out which using directives/references are causing the issue, but it occurred to me you might be able to tell at a glance. 

I also couldn't tell if there was a reason to use the .dll in the base Assembliesv4.2 directory or the le directory; they seemed to be the same file.  Without a reason to do otherwise, I stuck with the base directory version.

Very curious about whether the using directives/references solution makes sense, but very glad the board is working!

Thanks,

John Mc

Copying from the Netduino 2 Plus 4.2.2 firmware thread--looks like it might have been missed there, and seems like it might be misplaced there, anyway.

Tried flashing with 4.3 beta 1; it went smoothly, and the first time I started debugging, the program deployed without incident from Visual C# 2012.  The second time I deploy, Visual Studio gives, "There were deployment errors--continue?"  The output window shows "cannot attach debugger engine."  After answering "No" to "Continue?" the error list shows "unable to connect to device."  Curious, I ran MFDeploy; it says there is "No debugger!" found and "Cannot find any entrypoint," although the Device Capabilities info all seems to say 4.3.0.0 (beta 1).  The program I initially deployed is identified by name in MFDeploy.  The IP address shows as 0.0.0.0, if that matters.

I erased and re-flashed with 4.3 beta 1 to verify it wasn't a one-time event.  Same results.  As I recall, this is the same thing that happened with 4.2--it seemed to work the first time from Visual C# 2010, but didn't after that.

Am I missing something obvious, or have we reached RMA stage?

Thanks,

John Mc

Hmm...interesting results.

Flashing with 4.3 beta 1 went smoothly, and the first time I started debugging, the program deployed without incident from Visual C# 2012.  (Silly side question--how is the onboard LED now declared?  Haven't looked for it since 4.1.)

The second time I deploy, Visual Studio gives "There were deployment errors--continue?"  The output window shows "cannot attach debugger engine."  After answering, "No," the error list shows "unable to connect to device."  Curious, I ran MFDeploy, it says there is "No debugger!" found, and "Cannot find any entrypoint," although the other Device Capabilities info seems to all say 4.3.0.0 (beta 1).  The program I initially deployed is identified by name in MFDeploy.  The IP address of the device shows as 0.0.0.0 in MFDeploy, if that matters.

I erased and re-flashed with 4.3 beta 1 to verify it wasn't a one-time event.  Same results.  As I recall, this is the same thing that happened with 4.2--it seemed to work the first time from Visual C# 2010, but didn't after that.

I'm hoping the answer is, "Oh, based on those symptoms, it looks like you forgot to do X," but I'm worried the answer is, "That's not supposed to be possible."

Ideas?

--John Mc

Just received my shiny new Netuduino 2 Plus, to replace a Netduino Plus that seems to have died.  When I plug the new board in, I get "The USB device you installed has malfunctioned, and Windows does not recognize it."  After trying a couple times, Windows 8 showed me it still has a Blue Screen Of Death ("Unexpected kernel trap error"). 

Okay, try Windows 7.  Same error, but no BSOD.  MFDeploy saw the board, but wouldn't show Device Capabilities or ping it, so the simplest solution seemed to be erasing and reflashing the firmware.  That seemed super easy. MFDeploy now reports the firmware 4.2.2.2, but Visual Studio 2010 reports an error, 'Could not read state file "objDebugTinyCLR_DebugReferences.cache". Object must implement IConvertible.'

Checking again, MFDeploy now reports "Error--no response from device" when I try to ping it.

At this point, I'm not sure what to try next.  I'm hoping I just missed something--I had flashed the old Netduino Plus to 4.2, so I have the 4.2.2 SDK and 4.2 .NET Micro Framework installed.

Any ideas?  Well, I suppose that should be any ideas other than an RMA?

Thanks,

John Mc  

Progress.  I thought again about the 232-to-TTL shifter (using a Sparkfun PRT-0449), and I finally realized I had wired it backwards in my earlier, failed attempt.  Since the sonar is operating at RS-232 level, then for the purpose of the shifter, the sonar is the computer/DTE.  The Netuduino operates at TTL, so that makes it the modem/DCE.  Tx from the sonar to the DB-9 Tx pin; Tx from the shifter to the Netduino Rx pin; one null modem cable now operating.

I am now getting valid decimal bytes--82 for R, three 2-digit decimal numbers representing the 3 digits of the range, and decimal 13 for CR.  I'm still not getting 5 bytes consistently, but since Realterm read it fine, that tells me I'm doing something wrong in the code.

Finally had the chance to dig out my old computer with a physical serial port.  Using Realterm, and plugging the sonar directly into the DB-9 serial port, the sonar is happily banging away with RxyzCR at a rate of 9600 baud.  So, that tells me sensor is working.  That leaves my coding or the connections to the Netduino Plus (not really a surprise).  I'll email directly, and any solution we find should absolutely be posted for others to use.

I keep thinking about whether there's a signal issue between the Maxbotics sonar and the Netduino Plus.  The Netduino doesn't use RS-232 signal levels.  I did try using a 232 to TTL converter, but I could have easily messed that up.  At this point, I could use the sonar's analog mode to get the data I need, but it's such a simple interface that it seems like the perfect tool to figure out where I'm going wrong with my serial coding and the Micro Framework.  My project will require reading serial data from other sources that aren't as handy in providing an analog or PWM alternative.

I should note, for others, that I wrote some rough code to check for noisy data, as suggested by your website.  The sonar readings are very stable (within 10%).

--John Mc

[font="arial, helvetica, sans-serif;"]_{I am using 8 data bits, 1 stop bit, no parity.  On the Netduino, I'm using the COM port that doesn't have flow control (although I tried the other one; no difference).}  [/font]

[font="arial, helvetica, sans-serif;"]_{I am able to read range data using the analog pin on the sonar; the received values make sense.  I haven't tried using PWM.}[/font]

[font="arial, helvetica, sans-serif;"]_{What I can't figure out is why I'm not getting 5 bytes systematically, and I never see the "R" that should be the first byte sent.  I keep thinking I must be inverting some signal, or reading something backwards.  I've read everything I can find on the Maxbotics website about the LV-Maxsonar line (that's how I decided on the EZ3), but I may still be missing something obvious.}[/font]

[font="arial, helvetica, sans-serif;"]_{Looking very closely at the sonar (big magnifying glass), it does appear that the "X" in "TX" printed next to the transmit pin might have a connection to the circuit line above it (which I think is the 5V line).  I soldered a header to the sonar, so part of troubleshooting was to ensure I hadn't gotten solder where it didn't belong.  But, I don't see the lettering connect to anything else, so that's a stretch.}[/font]

[font="arial, helvetica, sans-serif;"]_{Looks like my next purchase will need to be a DB-9 to USB converter.  To this point, the sonar has only been connected to the Netduino; the Netduino is connected to the computer via USB.   I'm taking the serial values that the Netduino thinks it's getting and sending those to the Visual Studio output window.}[/font]