Serial input help! Hippy or anyone

Iver

New Member
Hi, I had given up on this project for almost a year but thought I'd have another try at it. Hippy suggested I could use my 08M to read serial output from commercial software that I want to use for my project. This is what he suggested I try.

Do
SerIn 3, n2400, b0
b1 = $FF
LookDown b0,( $FC, $F8, $F0, $C0, $80, $00), b1
Loop While b1 > 5

I have only run this in the PicAxe program editor. My problem is this, all the signals that the program sends are two digits and the simulator only seems to read the first digit. The result is that the lookdown command can't tell the difference between FC,F8 or F0. Is there a way to write this so both digits are recognized or is this a hardware limitation? This is my first PicAxe project so I my be making a very simple user error.
Thanks for any help.
-Iver
 

hippy

Ex-Staff (retired)
You'll need to read the two digits, such as with -

SerIn 3, n2400, b0, b1

Then you'll need to convert those two ASCII characters into a single number -

If b0 > "9" then
b0 = b0 - "A" + 10
Else
b0 = b0 - "0"
End If
If b1 > "9" then
b1 = b1 - "A" + 10
Else
b1 = b1 - "0"
End If
b0 = b0 * 16 + b1

You might want to handle that conversion better as it will give incorrect results for anything which is no 0-9, uppercase A-F
 

Dippy

Moderator
Well, as its a year I can't remember what you're doing.

Just a few Qus for clarification.

1. "all the signals that the program sends are two digits"
- just confirm you are referring to the "commercial software"?

2. "..two digits.."
- are these 2 unrelated bytes?
- are they 2 bytes that make a word?
- 2 "digits" can be ambiguous.
- or are they 2 decimal digits e.g. 45 in one byte?
- or are they 2 Hex digits?
- or what?

3. Are you happy with HEX?
- you realise that $FC is decimal 252 . So 2 hex 'digits' and 3 decimal digits, but ONE byte.

4. Is this "commercial software" outputing the number(s) as a real number e.g. 45 as a single byte or changed so that it reads prettily on a Terminal e.g. 52,53 i.e. = "4" , "5".

I only ask these things so that people don't start confusing issues.
And remember, you know your 'commercial software', the rest of us are running on CBP and CGW.

EDIT: Oh, hippy has replied. He'll sort you....
 

frank_p

Member
You are only reading the first byte:

serin 3,n2400,b0

If you need to read more than 1 byte add more memory locations after b0 separated by commas.

e.g. serin 2,n2400,b0,b1

Also depending on what you want to do, if the first byte you don't need it you can either discard the value in b0 above or else if the first byte is always the same, coming from the same source you can put it as a qualifier, e.g.

serin 3,n2400,($0A),b0

The $0A is the qualifier.

Hope this helps.
 

Iver

New Member
Hi all, thanks for the response. My project is a filter wheel for an astronomy camera, the software is a comercial astronomy camera control. these are the signals it sends for each of the six filter positions.
1= FC
2= F8
3= F0 each value was repeated 51 times
4= C0
5= 80
6= 00

-Iver
 

hippy

Ex-Staff (retired)
@ Iver : The question really is, how do these 'signals' come out, is FC sent as two letters, "F" then "C" or what ?

My crystal ball suggested two letters, two hexadecimal ASCII digits, but it could be wrong; it's last year's model :)
 

Iver

New Member
I'm starting to remember why I gave up on this project in the first place!:)

I used the emulator at this link to find the serial output from the astronomy software. http://www.picaxeforum.co.uk/showthread.php?t=8961

Is it possible for me to just use raw characters instead of ASCII?

I'll try to dig up my original question to this forum.


-Iver
 

Iver

New Member
OK, I did some reading about ASCII and came up with this. It works with the simulator, so if the signal that my software sends is ASCII do you think this would work once loaded into my PIC? By "Work" I mean assign a 0-5 value for b2.

do
SerIn 3, n2400, b0,b1
let w0= b0+b1
lookdown w0,("1","~","v","s","h","`"),b2
serout 1, n2400, (b2)
loop

-Iver
 

hippy

Ex-Staff (retired)
@ Iver : You really need to tell us exactly what the data sent out / shown by the terminal emulator is otherwise it's like asking, "I have ingredient A and ingredient B, if I mix them together will it make a nice cake ?", but without telling us what A and B are.

w0=b0+b1 probably isn't what you need, although it may work if the data is right, same for the LOOKUP, hence we need to know what the raw data values are.

The best approach would be to watch the data sent using the terminal emulator, having selected "Display Hex", take a screenshot and post that as an attachment. That way we can clearly see what you are seeing.
 

lbenson

Senior Member
If you look at your received 2-byte signals as ASCII representations of hexidecimal representations of bit patterns of a single byte, you have the following:

1= FC %11111100
2= F8 %11111000
3= F0 %11110000
4= C0 %11000000
5= 80 %10000000
6= 00 %00000000

So each consecutive signal represents an additional bit going off (except for the two bits going off between 3 & 4. I don't know your equipment, so I don't know what this signifies. If you want to reconstruct the original byte (which might or might not be otherwise helpful), you can do the following (assuming the two characters are in b0 and b1 and the result will be in b0).
Code:
  if b0 > "9" then ' it will be "A-F" (you may want error checking to confirm this)
    b0 = b0 - "A" + 10 * 16 ' converts to raw binary and shifts it to the high-order nibble
  else b0 = b0 - "0" * 16 ' ditto
  endif
  if b1 > "9" then ' it will be "A-F" (you may want error checking to confirm this)
    b0 = b1 - "A" + 10 + b0 ' converts to raw binary and puts it to the low-order nibble
  else b0 = b1 - "0" + b0' ditto
  endif
Now the binary pattern shown above is in b0. You can use the hexidecimal representations in your lookdown or decimal representation of your hex numbers:
Code:
b2 = 9 ' known invalid result
lookdown b0,( $FC, $F8, $F0, $C0, $80, $00), b4
sertxd(#b2) ' show the result--if 9, input was invalid
This will give you a result in b2 of 0-5, or 9 if the input was invalid.

Hope this helps.
 
Last edited:

vttom

Senior Member
Here's an idea...

Since there is still some debate about what the data looks like coming from the "commercial software", try this:

Write a short program on the PICAXE more-or-less like the following:

do
serin (pin), N2400, b0, b1, b2, b3, b4, b5, b6, b7
sertxd (#b0, " ", #b1, " ", #b2, " ", #b3, " ", #b4, " ", #b5, " ", #b6, " ", #b7, 13, 10)
loop

Then hook it up to the data source, run it, try a bunch of different filter positions, and report back here what the numbers are that get echoed back to the PC through the PICAXE.
 

Iver

New Member
Well, my ignorance of serial protocol is very obvious. Thank you all for your efforts. I'll try to educate my self a bit better before seeking more assistance.

vttom- thanks for your suggestion that sounds like something I can handle, I'll give it a try.

Ibenson- thanks for your help however that went way over my head!:)

Hippy- I tried the terminal emulator but for some reason can't get it to work. I made a null modem cable and connected my software to one serial port and the emulator to the other when I send a command nothing happens? Last April I used the terminal emulator with no problems. I'll try it again tonight. I emailed the software author for help and pasted my post from April and your reply below.
Thanks again,
Iver

<Hi again, I just tried the terminal emulator the results are as follows for each of the six positions.

1= FC
2= F8
3= F0 each value was repeated 51 times
4= C0
5= 80
6= 00


@ Iver : Looks like consecutive number of bits set/ clear is the key, so this code will read the byte and determine the wheel position 1 .. 6 in b1


Code:
Do
SerIn RX_PIN, RX_BAUD, b0
b1 = $FF
LookDown b0,( $FC, $F8, $F0, $C0, $80, $00), b1
Loop While b1 > 5
b1 = b1 + 1 ' Leave this out for a result 0..5 rather than 1..6
>
 

lbenson

Senior Member
Iver--is there information about this equipment available somewhere on the web? The returned values which you quote for the various filter positions, FC, F8, F0, C0, 80, 0, appear to me somewhat complex for just specifying 6 different filters used singly, but do make sense (based on the bit patterns), if they were specifying 6 or 8 filters which could be used in combination. For instance, given the value $F0, or binary %11110000, it might signify (counting from the right) that filters 5,6,7,&8 were in place, whereas $C0, binary %11000000, might signify that filters 7&8 were used. This is purely speculative, tho, so it might be nice to see what the equipment actually does. Crystal ball is older model, X2 version not out yet.
 

Iver

New Member
Hi Ibenson, I've searched the web and have not found any info. about what protocol is used. There are about 6 companies that make filter wheels for astronomy, but it's a niche market and that makes them rather expensive, $800 to $1200 without filters. That's why I made mine! They are all just basically a wheel with 6 to 12 filter positions that the user can install filters into. None allow multiple filter selection, one at a time only. I don't know why the code would be so complex? The one I'm trying to emulate only supports 6 filters, and was the only driver that didn't throw a "Filter Wheel not found" message when I tried to connect to it.

In your example does the $ identify the protocol as ASCII and the % as raw binary? It seems like I could just use binary since I'm just dealing with 6 variables.
 

lbenson

Senior Member
"%" signifies that a binary number follows, e.g. %10 would evaluate as decimal 2; "$" signifies that a hexadecimal number follows (hex for short), e.g. $02 evaluates as decimal 2.

For single-byte (8-bit) numbers, a binary number has 8 digits, each of which can have a value of 0 or 1. These can represent decimal numbers between 0 and 255. These bit-values are often used to represent the existance or absence of a condition. For instance, if they were used to represent the presence or absence of filters which could be used in conjunction (I know you say these cannot be), then %00100001 could indicate that the "zero"th filter and the fifth filter were simultaneously in place.

A single-byte hex number has two "digits", which can have values of 0-9 and A-F, where "A" represents 10, "B" is 11, and so on, with "F" equal to 15. This two-digit hex number also can represent decimal values between 0 and 255. The two digits of a hex number are sometimes referred to as "nibbles" (4 bits). %1111 is equivalent to $F and equals decimal 15. To calculate the decimal value of a hex number you multiply the decimal value of the high-order nibble by 16 and add the decimal value of the low-order nibble. For example, $EB equals 14*16 + 11, or 235.

Frequently (and this is the case with your values), the decimal value of a number represented in hex has no obvious significance. For instance, your value of $C0 is 192, which has no significance which refers to filters. But when looked at as a bit pattern, %11000000 might well be significant relative to %10000000.

To me, from the way you describe your equipment, the designer could have made the results you are looking for much more obvious by just returning a value between 0 and 6. There are probably historical reasons for the values actually returned, and they may have to do with setups which could potentially be much more complex--for example, perhaps there was equipment on which multiple filters could be used. It is also possible that the filters which you use have multiple elements or significant charactoristics, so that the filter which returns %11000000 filters light in two spectrum ranges, and another one which returned %11000001 would have added an additional range. This is purely speculative on my part.

A question. You say you basically have a wheel with 6 filter positions into which different filters may be placed. If you put filter "A" in position 1, does it return the same value as when you put filter "B" in position 1? If it is different, how do the properties of filter "A" and filter "B" differ? This could provide some insight into the significance of the bit patterns which are returned.

What I am getting at is that the returned value might be telling you not the position, 1-6, of the currently-used filter, but its physical characteristics, read somehow from the filter itself, e.g. UV filtering. Perhaps you could provide a description of the filters which you have.
 
Last edited:

Iver

New Member
vttom, what is the signifcance of the last two #'s in your code, 13, 10 ? I hope to have some time tomorrow to try this.

do
serin (pin), N2400, b0, b1, b2, b3, b4, b5, b6, b7
sertxd (#b0, " ", #b1, " ", #b2, " ", #b3, " ", #b4, " ", #b5, " ", #b6, " ", #b7, 13, 10)
loop
 

Iver

New Member
lbenson, thank you for that very detailed explanation. Now having reread your first post I think I understand it better. When you say "(you may want error checking to confirm this)" How is that done?

In answer to your question. The filters are glass in an anodized aluminum cell and would not be able to interface with the electronics. The software I use "AstroArt" has a filter set up window where the filter description is entered next to each filter position #.

Thanks again,
-Iver
 

lbenson

Senior Member
13 and 10 are the decimal values of the ascii characters, Carriage Return and Line Feed (CR & LF). The sertxd statement send the data to the program editor's terminal, and the CR, LF will cause the next sertxd statement to begin on a new line.
 

lbenson

Senior Member
>(you may want error checking to confirm this)" How is that done?

All of the received values which you quoted were 2-character pairs which were valid hexadecimal numbers (consisting of 0-9 and A-F). You could check to confirm this as follows (assuming that the two characters were in b0 and b1).

Code:
if b0 < "0" or b0 > "9" then
  if b0 < "A" or b0 > "F" then
'  you have an error condition here which must be dealt with
  endif
endif
if b1 < "0" or b1 > "9" then
  if b1 < "A" or b1 > "F" then
'  you have an error condition here which must be dealt with
  endif
endif
>software I use, "AstroArt", has a filter set up window where the filter
>description is entered next to each filter position #

What kind of description do you enter--is it text or is it clicking checkboxes (which might result in the bit patterns that you see)?
 

Iver

New Member
I received a reply from the manufacturer of the filter wheel I am trying to emulate.

Here is the info:

The pulses are separated by a gap of 11 milliseconds (fall of one to rise of next).

The pulse width controls the target filter position as per the following.

Position Pulse width in microseconds

1 550

2 810

3 1120

4 1400

5 1710

6 2000



The pulses can be from 4V to 12V in amplitude. The above values can be varied about 10% without and problems"
 

BeanieBots

Moderator
Yes, those pulse widths at that rate can be read by a PICAXE.
At standard clock speeds, pulsin will return values in 10uS steps, so the numbers returned would be the those numbers divided by ten.
The 'gap' of 11mS does leave a lot of space for doing any serial out but the bulk of other commands take around 250uS, so you could execute about 40 lines of 'simple' code between each pulse.
 

hippy

Ex-Staff (retired)
It appears that the software is generating these required pulses by sending a single byte of binary data via serial, the number of bits set / clear ( along with the start bit ) determines what the width of the pulse will be.

There is no obvious reason the code in post #1 should not work if that is the case.

You could use PULSIN to receive the pulses but, as the controller generates serial, it would make a lot more sense to receive serial; it should be easier to code and likely use much less program space. That's the data being sent, that's the data which is best to use.

The pulse lengths the wheel manufacturer suggests do not tally with the byte values used at the baud rate suggested by the software ( $FC = 3 x bit-time = 1250us @ 2400 baud ). The first thing is to determine what the actual data is that is sent by the software, as has been suggested a number of times.
 

Iver

New Member
I was able to get the terminal emulator working with my older pc. see image 1
sent at 2400 baud
recd at 2400 baud
Position 1 and 2 recd. FE
position 3 recd. FC
positin 4 and 5 recd. F8
position 6 recd. F0

sent at 2400 see image 2
recd at 4800
position 1 recd. FC
position 2 recd. F8
position 3 recd. F0
position 4 recd. C0
position 5 recd. 80
position 6 recd. 00

does this mean the my PICAXE can't read this code?

image 1



image 2
 

Attachments

Dippy

Moderator
Going right back to the start, and linking back all those aeons to the original post, I thought this device gave out a different PPM or PWM at the different positions?
And I thought that the timings just happened to give the data, convenient for reading by a PC+Terminal (or other prog)?

So why is so difficult to read with PICAXE?
Why can't you do pulse detection?

Or, by the looks of things, why can't you get PICAXE to read at 4800?
 

hippy

Ex-Staff (retired)
Enlightenment

I went back and re-read the original post in the light of where we now are ...

I have only run this in the PicAxe program editor. My problem is this, all the signals that the program sends are two digits and the simulator only seems to read the first digit ... This is my first PicAxe project so I my be making a very simple user error.
I think there are two inter-related problems -

1) Misunderstanding what the software sends to the PICAXE ( single byte, not two digits ) thus perceiving the code will not work.

2) Getting the simulator to inject the required one byte data into the simulated program.

The actual problem is that the simulator does not allow hexadecimal numbers to be specified. If you convert the desired values to decimal ( $FC = 252 etc ) and send those it works fine. When your program runs, enter 252, press send, b0 will be set to value 252 ($FC), the LOOKDOWN will place 0 in b1.

$FC = 252
$F8 = 248
$F0 = 240
$C0 = 192
$80 = 128
$00 = 0

As to why it's taken three pages of posts to arrive at what is quite a simple answer to the initial problem I think that comes down to issue (1); the code presented did not match what you described it should expect, that "program sends two digits" meant having to get to the bottom of exactly what was sent and what needed to be done in the code to use that.
 
Last edited:

vttom

Senior Member
(snip)
sent at 2400 see image 2
recd at 4800
(snip)
does this mean the my PICAXE can't read this code?
(snip)
If you do "setfreq 8m" on one of the smaller PICAXEs (e.g. 08M, 14M), and then use "N2400" with the serin command, it will actually receive @ 4800baud.
 

Iver

New Member
That was the problem, it works now.

Thank you all for your time and effort.

Sorry for the excessively long thread.

-Iver
 
Top