Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Servo signal

Status
Not open for further replies.

Kiko

New Member
Does anybody know how to simulate a R/C servo signal on the ISIS? Signal that come from R/C receiver and will go to PIC not coming from PIC to servo.

Tks
 
Gramo see if you or somebody can help me again...

My idea is to record the signal from an RC receiver in the PIC eeprom and then later on read this signal and send it to servo, but it's not only one signal, I mean it's not only one movement and I don't know how to do it, because it needs to record the time between the signals to make an exact movements recorded before.

rgds
 
It is a rather hairy task, a friend and I made a GPS 'auto pilot' for his RC Plane, and ran into some similar issues.

Basically you know that the RC signal will be sent every 50Hz, and usually has a maximum 2mS pulse(nominal figure for most RC Receivers). That means the PIC can record the time in mS, and have up to 18mS to do what ever it wants.

An 18F PIC micro can perform 180000 instructions in 18mS, so perhaps you see where this is heading.

Before I go further, why do you need multiple RC signals?
 
gramo said:
It is a rather hairy task, a friend and I made a GPS 'auto pilot' for his RC Plane, and ran into some similar issues.

Basically you know that the RC signal will be sent every 50Hz, and usually has a maximum 2mS pulse(nominal figure for most RC Receivers). That means the PIC can record the time in mS, and have up to 18mS to do what ever it wants.

An 18F PIC micro can perform 180000 instructions in 18mS, so perhaps you see where this is heading.

Before I go further, why do you need multiple RC signals?

It can be very usefull for RC pilots to have a kind of co-pilot help them to fly their planes. Imagine if you make a nice aproach and landing, record this stage of flight and then on the next flight the "co-pilot" can help you to make that nice landing again, if you make some mistakes... We can call this SCAS (Stability and Control Augmentation System). I can't figure out how to record the time between pulses. Basicallly an RC airplane have 4 channels then we need to record four signals individually.
 
If you need to log large amounts of data like that learn how to interface to SD/MMC cards. They're one of the more common flash memory storage devices out there and you can get them in sizes up to 4gig currently, and interface well with any micro controller which can use the SPI bus.

If you're recording servo signals and the readings are 8 bit in resolution and typically they don't go more than 8 channels at 50hz. That's 3200 bytes per second. On a 4 gig SD card that'd be 20,800+ hours of recording time. You can process the data to get the acceleration vector aftwards, or do it on the pic itself only storing the accleration vector based on a few buffer bytes.
 
Sceadwian said:
If you need to log large amounts of data like that learn how to interface to SD/MMC cards. They're one of the more common flash memory storage devices out there and you can get them in sizes up to 4gig currently, and interface well with any micro controller which can use the SPI bus.

If you're recording servo signals and the readings are 8 bit in resolution and typically they don't go more than 8 channels at 50hz. That's 3200 bytes per second. On a 4 gig SD card that'd be 20,800+ hours of recording time. You can process the data to get the acceleration vector aftwards, or do it on the pic itself only storing the accleration vector based on a few buffer bytes.

I'll need only a minute or 2 of data to record (for a while)... So the problem is how to do it. My main goal is to make a repeater of phases of flight, I push a button (let's say channel 5) on the transmitter so the pic (onboard) starts to record the four channels (1, 2, 3 and 4) then whenever I want I push another button (channel 6) and the pic will play it back. If I do it again the pic will erase the previous record, doesn't matter. But I'm a beginner programming pics and I can't figure out how to record these signals and time these signal will take.
 
There's one problem with record and playback for flight data at that length. It doesn't work over that length of time. Air currents and other flight characotoristics will distort the recorded movement on playback and result in different end movements. It might work for pattern flying on a finely tuned aircraft over 5 seconds or so, but not for flight path reproduction with any degree of accuracy over a few minutes.
 
Cool video, gramo. Bit of a problem adding up to 20ms PWM period until you got to the 19ms + 1ms part, though. Still, it's just 1ms - who's gonna miss it?
 
A true RC PPM signal is much more complicated then that though... There's multiple edge detected PWM signals demultiplexed depending on the placement of a master 'frame pulse' signal of a longer than the maximum pulse width.
 
Sceadwian said:
There's one problem with record and playback for flight data at that length. It doesn't work over that length of time. Air currents and other flight characotoristics will distort the recorded movement on playback and result in different end movements. It might work for pattern flying on a finely tuned aircraft over 5 seconds or so, but not for flight path reproduction with any degree of accuracy over a few minutes.

I thought about that and that's why I want to record only about a minute, may be I can put some gyros in the future to correct any undesirable movements and another idea is to use it as a flight data record, then it's going to need an SD card.

But first of all let's learn how to record the data.

Thanks
 
Putting so many ideas into one project might be a bad way to go about this!

Start simple, learn how to intercept and monitor RC servo signals, then take on the recording side of things separately.

There are a lot of variables with this 'simple' concept, and it will probably not be worth the effort, perhaps a simple RC buddy system would be a simpler option :eek:
 
gramo said:
Putting so many ideas into one project might be a bad way to go about this!

Start simple, learn how to intercept and monitor RC servo signals, then take on the recording side of things separately.

There are a lot of variables with this 'simple' concept, and it will probably not be worth the effort, perhaps a simple RC buddy system would be a simpler option :eek:

You're right I need to learn how to record those datas first, if you have any ideas please let me know.

Thanks
 
If your still using Proton, what about the PulsIn command?

From the help file;
Pulsin acts as a fast clock that is triggered by a change in state (0 or 1) on the specified pin. When the state on the pin changes to the state specified, the clock starts counting. When the state on the pin changes again, the clock stops. If the state of the pin doesn't change (even if it is already in the state specified in the Pulsin instruction), the clock won't trigger. Pulsin waits a maximum of 0.65535 seconds for a trigger, then returns with 0 in variable. The variable can be either a word or a byte . If the variable is a word, the value returned by Pulsin can range from 1 to 65535 units.

The units are dependant on the frequency of the crystal used. If a 4MHz crystal is used, then each unit is 10us, while a 20MHz crystal produces a unit length of 2us.

If the variable is a byte and the crystal is 4MHz, the value returned can range from 1 to 255 units of 10µs. Internally, Pulsin always uses a 16-bit timer. When your program specifies a byte, Pulsin stores the lower 8 bits of the internal counter into it. Pulse widths longer than 2550µs will give false, low readings with a byte variable. For example, a 2560µs pulse returns a reading of 256 with a word variable and 0 with a byte variable.

So you could use something like

Code:
Device = 16F877A
XTAL = 20

Dim Result As Word

While True
     Result = PulsIn, PORTC.0, 1
     Result = Result * 2                   ' Scale to uS (20Mhz Clock = 2uS increments)
     PrintAt 1, 1, DEC5 Result, " uS"      ' Display result on an LCD
Wend
 
gramo said:
If your still using Proton, what about the PulsIn command?

From the help file;


So you could use something like

Code:
Device = 16F877A
XTAL = 20

Dim Result As Word

While True
     Result = PulsIn, PORTC.0, 1
     Result = Result * 2                   ' Scale to uS (20Mhz Clock = 2uS increments)
     PrintAt 1, 1, DEC5 Result, " uS"      ' Display result on an LCD
Wend

I'm using Proton and I have made some experience using Pulsin and servo commands with good results, but I'm a little confusing in writing data to eeprom (internal and external), so if you have any exemple with explanation I'll apreciate.

Tks
 
Kiko said:
I'm using Proton and I have made some experience using Pulsin and servo commands with good results, but I'm a little confusing in writing data to eeprom (internal and external), so if you have any exemple with explanation I'll apreciate.

Tks


Here's a copy and paste from one of my Proton examples;

The EEPROM on a PIC micro is memory that can contain information even while the PIC is turned off. This is useful for storing data/passwords/key information that is changeable, but required by the program.

Reading and writing to/from the PIC's EEPROM is very simple with a higher programming language such as Proton+, and is as simple as the following;

Code:
        Variable = [B]EREAD [/B]Address

        [B]EWRITE [/B]Address , [Variable, Variable]


The type of variable being save will determine the amount of EEPROM memory that will be written too. For example:

Code:
        Dim Large_Variable[B] As DWord

        EWRITE[/B] 00, [Large_Variable]

The above example will write Large_Variable to address 00 of the PIC's EEPROM. But because DWord's contain 4 bytes of information, addresses 00, 01, 02, 03 will be written too. You must take things like this into account. Other examples are Words take 2 Bytes, or Floats take 4 Bytes etc.

Reading from the EEPROM is just as easy, and a quick look at the Proton Help file will guide you in the right direction.

Note: PIC's, like other EEPROMS, can only be written too 1,000,000 times by the datasheet. In reality, this value can be as low as 100,000. Do not write to the EEPROM in a continues loop - use it sparingly. There is no limit on reading EEPROM data however.

Here's a small program displaying an EEPROM read and write;

Code:
        [B]Device [/B]= 16F877
        [B]Xtal [/B]= 4

        [B]Dim [/B]DWord_Var as DWord
        [B]Dim [/B]Word_Var as Word

        [B]Dim [/B]Temp_DWord as DWord
[B]        Dim [/B]Temp_Word as Word

        LCD_DTPIN = PORTB.4
        LCD_RSPIN = PORTB.2
        LCD_ENPIN = PORTB.3
        LCD_INTERFACE = 4
        LCD_LINES = 2
        LCD_TYPE = 0

        [B]All_Digital[/B] = True

        [B]Delayms [/B]150
        [B]Cls[/B]

        DWord_Var = 1000000
        Word_Var = 1000

        Main:

        	 [B]EWrite [/B]00, [DWord_Var, Word_Var]
        	 
        	 Temp_DWord = [B]ERead [/B]00
        	 Temp_Word = [B]ERead [/B]04
        	 
        	 [B]Print At[/B] 1, 1, DEC7 Temp_DWord
        	 [B]Print At[/B] 2, 1, DEC5 Temp_Word
        	 
        	 [B]Inc [/B]DWord_Var
        	 [B]Inc [/B]Word_Var
        	 
        	 [B]DelaymS [/B]1000
        	 
        	 [B]Goto [/B]Main

Click here to watch this program in action!


Hope that helps you out


:)
 
Gramo thank you.

Let me ask something, as I did not have any class about programming pics I can't understand whem you say 1 byte, 2 bytes, etc... I know 1 Byte is 8 bits but I can't make a relationship between a real number or word as bit/byte. For example: Let's say I have a number (1345) or a word (test). How many bits or bytes does it have?

I know it's a basic of programming and perhaps is a stupid question.

Thank you again
 
Kiko said:
Gramo thank you.

Let me ask something, as I did not have any class about programming pics I can't understand when you say 1 byte, 2 bytes, etc... I know 1 Byte is 8 bits but I can't make a relationship between a real number or word as bit/byte. For example: Let's say I have a number (1345) or a word (test). How many bits or bytes does it have?

I know it's a basic of programming and perhaps is a stupid question.

Thank you again


Not at all, it’s a problem that’s common with micro controllers and programming (for both assembler and higher languages)

Put simply, 1 Byte = 8 Bits

Lowest value of a byte = 00000000 (8 zero's)
Highest value of a byte = 11111111 (8 ones)

Remember that each place value of a byte is worth a value.
So;
00000001 = 1
00000010 = 2
00000100 = 4
00001000 = 8​

Notice each place is worth twice the value before, and that bytes are right justified

If multiple bits are high, you just add each place value, eg;

00001011

Means 8 + 2 + 1 = 11

I'm leading this to explaining what the maximum value for a byte is, and that is 11111111 (8 one's) = 255. Now that's not a very big number...

You can join two bytes together, and use all 16 bits as one register. Now our largest value is 1111111111111111 (16 ones) = 65535. Now that's looking better! Go ahead and try that in your calculator.

Strings... Text or Strings are a rather inefficient way of working with things, but many devices require you interface with them with strings. An example of this is the humble 16 * 2 LCD.

An **broken link removed** (put your mouse over any letter to see its ASCII value with that link) contains a chart in which any value from 0 to 255 means a letter. With this in mind, each letter/character will require 1 Byte. Most (all) compilers require you to terminate your string/text with a null (ASCII 0)

You needn't worry though!!

Higher languages are structured to do all of this "on the fly". This knowledge just helps explain why when writing/reading to the EEPROM (internal/external), that some variables take more Bytes (memory) than others ;)

Here are some examples;
**broken link removed**


Back to your original question in the previous post;
The number 1345 could be stored in a Word (16 Bits = 0 to 65535)
The String text would require 5 Bytes, one for each letter followed by a null



:)
 
Last edited:
Status
Not open for further replies.

Latest threads

Back
Top