Shop OBEX P1 Docs P2 Docs Learn Events
frqa := $ frqa := $ frqa := $! Edit: Not a hex number! — Parallax Forums

frqa := $ frqa := $ frqa := $! Edit: Not a hex number!

bill190bill190 Posts: 769
edited 2011-06-15 04:10 in Propeller 1
Edit: This turns out to not be a Hex number! Read all the following posts to see where my error was...


Well this time it was a simple "$" I left out...

I spent all day tracking down a frequency problem and it turned out that I needed this...

frqa := $2146225

...rather than what I had, which was this...

frqa := 2146225

Last time I spent so much time tracking something down, it was a missing comma...

Always something simple, but finding it can be a royal chore sometimes!


Post Edited (bill190) : 5/12/2010 4:31:50 PM GMT

Comments

  • T ChapT Chap Posts: 4,224
    edited 2010-05-12 05:01
    You can use $ or not, you can represent a value in decimal, hex, or binary and achieve the same effect with the counter. The main thing is to know the actual value you need to use, then choose your preference of writing the number.

    $02146225 = 34890277 = %0010000101000110001000100101

    Post Edited (Todd Chapman) : 5/12/2010 5:11:39 AM GMT
  • pullmollpullmoll Posts: 817
    edited 2010-05-12 05:14
    Here's one I hadn't found for several days: 
    ...
                        rdbyte  portff, portff_ptr              ' get current port $FF value
                        test    portff, #%00000100        wz    ' background enabled?
        if_nz           mov     z, bgcolour_1                   ' yes, use background colour 1
        if_nz           jmp     #:newbg
                        mov     z, bgcolour_0                   ' no, use background colour 0
                        test    portff, #%01000000        wc    ' except if bits 6
                        test    portff, #%10000000        wz    ' or 7 are set
        if_c_and_z      mov     z, bgcolour_01                  ' select background color 01
        if_nc_and_nz    mov     z, bgcolour_02                  ' 02
        iv_c_and_nz     mov     z, bgcolour_03                  ' or 03
:newbg                  mov     bgcolour, z
...



    Do you see it? The condition "iv_c_and_nz" isn't a condition, but a label! The compiler doesn't complain and the code is executed unconditionally.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-05-12 05:32
    Pullmoll,

    Some compilers/assemblers generate warnings about "unreferenced labels/symbols". That would have been helpful here -- as would a simple rule that labels have to begin in column one or end with a colon. That your typo was not caught by the assembler, and at least flagged with a warning, should alert the compiler/assembler author(s) that a fix is needed.

    -Phil
  • pullmollpullmoll Posts: 817
    edited 2010-05-12 05:43
    Phil Pilgrim (PhiPi) said...
    as would a simple rule that labels have to begin in column one or end with a colon.

    I think the former rule could be introduced without causing too much trouble, if any, because all code I've seen had labels starting in column one. Perhaps this rule can be made an option in BST, if not the default.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Pullmoll's Propeller Projects
  • bill190bill190 Posts: 769
    edited 2010-05-12 14:30
    Actually I was using the following formula for my frqa calculation and it does not specify hex...

    frqa = ( (2 to the 32)· / clock frequency ) x frequency you want in Hz) (Which will be the PHS bit 31 frequency and output directly from there·to the pin specified for APIN [noparse][[/noparse]ctra[noparse][[/noparse]5..0] := Pin_Number].)

    The frequency I got was close once I added the $, however still a little off.

    I used decimal numbers for all of the above. Are any of the numbers used in the calculation above supposed to be hex as well?


    Post Edited (bill190) : 5/12/2010 2:37:09 PM GMT
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-05-12 15:00
    You may have to do the calculations with floating point constants and then convert back to fixed point.· I'm not sure how the compiler handles fixed point constants greater than $ffffffff.· I wrote a small program that generates an FM signal around 100 MHz, and I used floating point to compute the constants.

    Maybe one of the Prop gurus can verify whether the computations can include fixed point constants larger than 32 bits.

    Dave
  • bill190bill190 Posts: 769
    edited 2010-05-12 15:29
    I just need a fixed frequency of 38kHz, so I'm not doing the calculation in the software, just sticking in·a whole·number from·a regular calculator and calculated using decimals.

    I'm using NCO single pin/single-ended mode [noparse][[/noparse]ctra[noparse][[/noparse]30..26] := %00100]. And I read this...

    "For values of FRQA which are not a power of 2, ( FRQA ? 2N ) there will be jitter present on the output signal since the most significant bit of PHSA will toggle at an inconstant rate."

    So I'm using the following numbers, the first being what I calculated (then the·nearest x2 number), then I tried a little higher to get closest to 38kHz. The 3rd number works best and is a power of 2 number. (14692)

    '· frqa := $2146225·······
    '· frqa := $2149156······
    · frqa := $2157961

    FYI - I'm using the following Basic Stamp code to measure the frequency with a direct pin to pin connection as well as ground connection between the Propeller and Stamp. (This also reads 38kHz with a 555 timer I have set to the same frequency.)

    ' {$STAMP BS2}
    ' {$PBASIC 2.5}

    cycles VAR Word

    DO
    · COUNT 15, 100, cycles
    · cycles = cycles * 10
    · DEBUG "Frequency = ", DEC5 cycles, " Hz"
    · DEBUG CR
    LOOP
  • RaymanRayman Posts: 14,984
    edited 2010-05-12 15:48
    I think it should be frqa:= 2040109 (no dollar signs)

    That is, assuming you are running at 80MHz and have the right crystal settings in the CON section...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

    My Prop Products:· http://www.rayslogic.com/Propeller/Products/Products.htm
  • bill190bill190 Posts: 769
    edited 2010-05-12 16:26
    Rayman said...
    I think it should be frqa:= 2040109 (no dollar signs)

    That is, assuming you are running at 80MHz and have the right crystal settings in the CON section...

    You are exactly right!

    I was going to reply to this and say it helps to mention what frequency I am using (80 MHz) and these are the settings in my "top" object...

    · _clkmode = xtal1 + pll16x···················· ' Crystal and PLL settings
    · _xinfreq = 5_000_000

    ...then I suddenly realized I·have the frequency running in a different object and that·might not have the·clock set in it... And I used that object running by itself for·measuring just the frequency...

    So my frequency measurement yesterday was at the default clock speed!

    I just added this to the top of my frequency object so it would run at 80MHz when run by itself...

    · _clkmode = xtal1 + pll16x···················· ' Crystal and PLL settings
    · _xinfreq = 5_000_000

    ...then measured my frequency again and it was 34.354 kHz!

    Then switched it to frqa:= 2040109 (your number in decimal) and now get 37.940 kHz!

    I'll use something which gets an even square root, so 2042041 or 2044900 are the closest to 38 kHz I'm finding (14292, 14302).

    ·
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-05-12 16:55
    I'm not sure why your using a number with an integral square root.· If you want to minimize jitter than you want a number that can be represented as n << m, where n is as small as possible.· The decimal number 2040109 is $1f212d in hex.· You could use $200000 with no jitter and a frequency of 39.063 KHz, or you could use $1f0000 to get 37.842 KHz with a little bit of jitter.

    Edit: $1f2000 will get you real close to 38KHz with a frequency of 37.994 KHz.

    Post Edited (Dave Hein) : 5/12/2010 5:03:33 PM GMT
  • bill190bill190 Posts: 769
    edited 2010-05-12 17:23
    Thanks for all this great help everyone!

    I'm going by the "AN001 - Propeller Counters v1.0" pdf which says on Adobe reader page 7...

    "For values of FRQA which are not a power of 2, ( FRQA ≠ 2N ) there will be jitter present on the output signal since the most significant bit of PHSA will toggle at an inconstant rate."

    That document is here...

    http://forums.parallax.com/attachment.php?attachmentid=59613

    FYI - This is for a Sony SIRC protocol IR transmitter. I am reading some places the carrier is 40 kHz and others 38 kHz. So actually the above number·I calculated was for 40 kHz and I do get the same number for 38 kHz using the above formula...

    2 to the 32nd power =· 4294967296.
    4294967296. / 80,000,000 = 53.6870912

    53.6870912 x 38,000 Hz (38 kHz) = 2040109.4656 (2040109)

    and...

    53.6870912 x 40,000 Hz (40 kHz) = 2147483.648 (2147483)
  • mparkmpark Posts: 1,306
    edited 2010-05-12 17:53
    bill190 said...
    The 3rd number works best and is a power of 2 number. (14692)

    14692 is not a power of 2.
  • Dave HeinDave Hein Posts: 6,347
    edited 2010-05-12 18:32
    I think you are confusing "raised to a power of 2" with a "a power of 2".· The former is a number squared, and the latter is shorthand for saying 2 raised to an integral power.· I can see how that would be confusing.

    I've played around with IR controllers a little bit, and I think most IR receivers are fairly tolerant of a wide frequency range.· I think the front-end bandpass filter they use is pretty wide.

    Dave
  • bill190bill190 Posts: 769
    edited 2010-05-12 23:04
    Yeaaa! burger.gif

    "We" actually got it to work! (That is to turn down the volume on my Sony receiver.)

    But my gizmo is still not working exactly like the Sony remote does with my frequency and bit testing software (works the same on the receiver), so I'll fiddle with it a bit (while I·study·my math too!)

    Thank you for your help everyone...

    P.S. Going to 40 kHz worked and acted more like my remote when I added in·the bit sending. My receiver is only a couple of years old.·I don't know if some are 38 kHz and others 40 kHz?
  • ChrisCantrellChrisCantrell Posts: 25
    edited 2011-06-15 04:10
    Thanks everyone! This is exactly what I needed. I used the frqa:= $1F_2000 value and the code in the "AN001 - Propeller-Counters" application note as you all suggested. My IR TV transmitter works great.

    The "jitter" comes in because the hex value "001F2000" does not divide evenly into "1_0000_0000" (2^32). When the 32-bit value in PHSA rolls over, it doesn't rollover to 0. There is a little left over. At the next rollover there is a little more left over. Eventually this rollover accumulates and you get a rollover one clock earlier than you did before.

    For instance, counting by 1F_2000 and watching the upper bit of PHSA you get:
    0 for 1053 counts
    1 for 1053 counts
    0 for 1053 counts
    1 for 1053 counts
    0 for *1052* counts **** accumulated rollover
    1 for 1053 counts
    0 for 1053 counts
    ... and so on ...

    Most of the time you count to 1053 with each output value. Occasionally you count to 1052. The most significant bit does not toggle "at a constant rate" as the app note warns. The only way to ensure the output rate is constant is to use a number that divides into 2^32 evenly. All powers of 2 do that (1,2,4,8,$10,$20,$40,...). And in fact, there are no other numbers but powers-of-two that divide perfectly.

    Jitter is a necessary evil. The hardware with a 5MHz crystal can't generate a perfect 38KHz signal. But it can get close over time. The delay between some pulses is sometimes fast ... sometimes slow. But the difference averages out in the wash.

    The TVs around my house are all forgiving. They don't seem to notice the slight jitter in the ~38KHz signal, and they don't notice the slight timing variations in my code to generate the PWM codes on top of the ~38KHz carrier.
Sign In or Register to comment.