WB 2010 Boards missing R43 Pads

[Lcstyle]

Hello all,

I am getting garbage in the terminal when connecting to the 168.

I burned the fuses, and flashed the main.hex. But I notice that I cannot flash the 168 while it is soldered to the board, I had to desolder it, connect the pins and flash it that way. I am wondering if something is awry on the board that is causing me to not be able to use my arduino as an ISP.

Also, I can hear the WB start up ( a small charging whine when i Press the power button (s2)) and the led flashes, so I know the atmel is doing something. Just can't get legible text in my terminal session using 19200 8n1.

Thanks in advance.

[jersagfast]

Have you tried burning the bootloader with the Arduino IDE? Do you have access to a USBTiny? What is the circuit that the 168 is in? Does it have an FTDI chip? Have you tried a lower baud rate (9600)? Is this a lot of questions?

EDIT - Just saw this was posted in Wave Bubble. Sorry for the overlook.. What version do you have?

[Lcstyle]

Thanks for the quick response,

So I learned a couple of things,

1. first to remove power to VCO's while programming (remove jp3 and jp4 connections).
2. My problem programming the 168 was removed when I removed the connection on jp7, disconnecting the 3.3v power rail from the atmel chip, since the programmer is providing its own Vcc.
3. I have the Arduino AVR ISP programmer now working and running using the AVR ISP port.
4. My WaveBubble is version 2010.
5. I have flashed the fuses and the main.hex
6. I now see the menu in garbage, and can press "a" for the led test and that works, so I am very close.

running at 9600 doesn't work..

I do have an FTDI chip, and when I connect to it from terminal and short the rx and tx lines I do see my own characters echo'd.

So the mystery is why am I getting garbage ascii...

[TheFallen]

Looks like I need to get my Arduino port working :/

[Lcstyle]

Looks like I need to get my Arduino port working :/

Finally got it working, thanks to all for help.

My 168 clock was OK, it was the fact that I was driving the RF board from an external power supply. I also swapped out the RS232 chip, but that initially didnt work. It wasn't until I powered the RF Board from the USB Batt Board that the comm's finally worked.

Still, my terminal screen isn't displayed nicely, the text tends to wrap around. As if the newline characters in the code weren't being paid attention to.

[Mictronics]

Can you show a screenshot of your terminal output?

[Lcstyle]

I already reflashed with the rc1 code, which displays the menu correctly (upon pressing space bar.) I am going to reflash back to the wb2010 code soon though, since apparently upon trying to tune vco1 (ros2700) to 1800mhz -> 1900 I get a "too high" error and I need to test the pll.
Any other suggestions regarding the too high or too low errors are welcome..

As soon as I flash back i'll post a pic of the terminal output.

[Mictronics]

Too high and too low are tuning errors.

It means the VCO has reached the limit while the PLL was not able to detect a frequency lock.

So either VCO is note tuning or PLL is not working correct.

[Lcstyle]

Thanks for the advice on the PLL + Tuning

As for the Terminal, here you go:

[westfw]

As for the Terminal, here you go:

A "proper" line ending for most terminals (and emulators) has both a "Carriage Return" ('\r') to reset the column, and a "line feed" ('\n') to advance to the next line. The screen you show is symptomatic of having only the linefeed at the end of the line. This is "standard practice" for unix and unix-like environments ("printf("Hellow World\n");") Usually the required '\r' is added by the operating system as part of the tty driver, or by the printf() library (on systems that don't have a TTY driver.) Or, many terminal emulators will have an option buried somewhere to "fix" this (http://the.earth.li/~sgtatham/putty/0.6 ... g-terminal Section 4.3.3)

[Lcstyle]

As for the Terminal, here you go:

A "proper" line ending for most terminals (and emulators) has both a "Carriage Return" ('\r') to reset the column, and a "line feed" ('\n') to advance to the next line. The screen you show is symptomatic of having only the linefeed at the end of the line. This is "standard practice" for unix and unix-like environments ("printf("Hellow World\n");") Usually the required '\r' is added by the operating system as part of the tty driver, or by the printf() library (on systems that don't have a TTY driver.) Or, many terminal emulators will have an option buried somewhere to "fix" this (http://the.earth.li/~sgtatham/putty/0.6 ... g-terminal Section 4.3.3)

Wow that is great! I noticed that the code has a \n as shown below, I thought all you needed was that!

pc_puts_P(PSTR("a - Power/Program LED test\n")); // TP1
pc_puts_P(PSTR("b - NE555 low frequency mode\n")); // TP2
pc_puts_P(PSTR("c - NE555 high frequency mode\n")); // TP2

I took a look at the code that printed the menu which worked which was the original WB Code, I see this putstring_nl function being called for printing menu items, and wouldn't you know it:
//call
putstring_nl(" p> Display progs");
//defined
#define putstring_nl(x) ROM_putstring(PSTR(x), 1)
//Rom_putstring contains guess what? a \r
}
if (nl) {
uart_putchar('\n'); uart_putchar('\r');
}

Thanks for the link, I have seen this putty option at least 10 thousand times and never made the connection.
You sir, are the man..

[Lcstyle]

Can anyone see why I would be having a tuning problem?

[jersagfast]

Yeah, it obvious, that board is labeled IC11, when quite clearly it should have been labeled, IC39. Uhh, I think..
I have done much worse, I promise.

[Lcstyle]

Yeah, it obvious, that board is labeled IC11, when quite clearly it should have been labeled, IC39. Uhh, I think..
I have done much worse, I promise.

EDIT - 7/28/2011 --- This has been confirmed as a problem.

VCO 2 is on the left should be ROS 1300, needing R43 and R45, but no way to place them because my board is missing traces there.



Here, We can't really figure out which VCO is which. Be assured that VCO 2 is on the left.

[Mictronics]

Your tuning problem is related to the fact that R40 and R43 are missing. They provide the frequency feedback to the PLL. Without this connection the PLL will never know what frequency of the VCO. Hence the AVR will not know when it reached the tuning point an therefore tunes the VCO up to the limit.
When reached you get either a "too low" or "too high" error.