Jump to content
43oh

tripwire

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    14

Reputation Activity

  1. Like
    tripwire got a reaction from zeke in SensorTag Altitude Logger   
    Recently I took a trip to the US, which offered a good opportunity to test my altitude logger by recording a profile of the whole journey there. The trace revealed some interesting details about the flights I took, and airline operations in general.

    Here's the profile for the entire trip:
     

     
    The x-axis shows elapsed time in minutes. The altitude is shown in metres, measured relative to the start of the trace (not too far above sea level). Despite that I'll be using feet as the unit of altitude here, since that's the standard used in aviation. Because the logger calculates altitude based on air pressure, it is affected by cabin pressurisation. Instead of recording the true altitude of the aircraft it gives a trace of the effective altitude inside the cabin.

    The first big peak at the blue cursor is a flight from Edinburgh to London Heathrow. Comparing the cabin altitude trace against real altitude data makes it easier to pick out the main features, so here's a chart showing this flight's altitude as broadcast over ADS-B:
     

     
    And this is a closeup showing what my altitude logger recorded for the same flight:
     

     
    The cursors mark where I think the flight started and finished, based on the fact that the plane was in the air for 70 minutes. From takeoff the pressure falls steadily until the effective altitude in the cabin is about 7000ft, at which point the aircraft is actually at 37000ft. After cruising there for 12 minutes the plane descends and cabin pressure steadily increases.

    The cabin pressure reaches ground level before the plane actually lands, so the trace stays flat for the next 12 minutes. In fact, this section of the trace is effectively below ground level while the plane approaches landing. The plane's environmental control system has deliberately overshot and pressurised the cabin to higher than ambient pressure at the destination. At the orange cursor marking the end of the flight you can see a slight increase in altitude. This is when the flight is over and the controller opens the pressurisation valve to equalise with the external air pressure.

    It seems this extra pressurisation is done before takeoff and landing to help the system maintain a steady pressure. There's a detailed explanation of the reasons for this here: http://aviation.stackexchange.com/questions/16796/why-is-cabin-pressure-increased-above-ambient-pressure-on-the-ground

    Now on to the second flight, which was from Heathrow to Dallas Fort Worth. First the ADS-B trace:
     

     
    And the altitude logger's version of events:
     

     
    Again, the cursors mark the start and end of the flight and line up with the reported duration. The "steps" along the top of the trace match up with changes in cruise altitude from 32000?>34000?>36000ft. Maximum effective cabin altitude is about 5500ft, lower than the first flight even when the lower cruise altitude is taken into account. I think that's down to the use of a newer 777 on the international flight compared to the A319 on the domestic route. Modern planes are increasingly designed to offer lower effective cabin altitudes for passenger comfort.

    The stepped flight profile is used to maximise fuel efficiency. Flying higher reduces losses to air resistance, but early in the flight the aircraft is heavy with fuel and climbing is expensive. As the fuel is burned off the optimal cruise altitude increases, so ideally the plane would climb to match. In fact the plane can't climb gradually because modern air traffic control regulations restrict aircraft to set flight levels. The best option under these restrictions is to perform a "step climb" up to a higher level when it's more fuel-efficient than the current one. The flight levels are multiples of 2000ft for flights from the UK to the US, which is why the steps are 32000->34000?>36000ft.

    Wrapping up, one of the things I hoped to test by recording this journey was high rates of altitude change. The altitude logger can currently handle rates of change up to
  2. Like
    tripwire got a reaction from bluehash in SensorTag Altitude Logger   
    Recently I took a trip to the US, which offered a good opportunity to test my altitude logger by recording a profile of the whole journey there. The trace revealed some interesting details about the flights I took, and airline operations in general.

    Here's the profile for the entire trip:
     

     
    The x-axis shows elapsed time in minutes. The altitude is shown in metres, measured relative to the start of the trace (not too far above sea level). Despite that I'll be using feet as the unit of altitude here, since that's the standard used in aviation. Because the logger calculates altitude based on air pressure, it is affected by cabin pressurisation. Instead of recording the true altitude of the aircraft it gives a trace of the effective altitude inside the cabin.

    The first big peak at the blue cursor is a flight from Edinburgh to London Heathrow. Comparing the cabin altitude trace against real altitude data makes it easier to pick out the main features, so here's a chart showing this flight's altitude as broadcast over ADS-B:
     

     
    And this is a closeup showing what my altitude logger recorded for the same flight:
     

     
    The cursors mark where I think the flight started and finished, based on the fact that the plane was in the air for 70 minutes. From takeoff the pressure falls steadily until the effective altitude in the cabin is about 7000ft, at which point the aircraft is actually at 37000ft. After cruising there for 12 minutes the plane descends and cabin pressure steadily increases.

    The cabin pressure reaches ground level before the plane actually lands, so the trace stays flat for the next 12 minutes. In fact, this section of the trace is effectively below ground level while the plane approaches landing. The plane's environmental control system has deliberately overshot and pressurised the cabin to higher than ambient pressure at the destination. At the orange cursor marking the end of the flight you can see a slight increase in altitude. This is when the flight is over and the controller opens the pressurisation valve to equalise with the external air pressure.

    It seems this extra pressurisation is done before takeoff and landing to help the system maintain a steady pressure. There's a detailed explanation of the reasons for this here: http://aviation.stackexchange.com/questions/16796/why-is-cabin-pressure-increased-above-ambient-pressure-on-the-ground

    Now on to the second flight, which was from Heathrow to Dallas Fort Worth. First the ADS-B trace:
     

     
    And the altitude logger's version of events:
     

     
    Again, the cursors mark the start and end of the flight and line up with the reported duration. The "steps" along the top of the trace match up with changes in cruise altitude from 32000?>34000?>36000ft. Maximum effective cabin altitude is about 5500ft, lower than the first flight even when the lower cruise altitude is taken into account. I think that's down to the use of a newer 777 on the international flight compared to the A319 on the domestic route. Modern planes are increasingly designed to offer lower effective cabin altitudes for passenger comfort.

    The stepped flight profile is used to maximise fuel efficiency. Flying higher reduces losses to air resistance, but early in the flight the aircraft is heavy with fuel and climbing is expensive. As the fuel is burned off the optimal cruise altitude increases, so ideally the plane would climb to match. In fact the plane can't climb gradually because modern air traffic control regulations restrict aircraft to set flight levels. The best option under these restrictions is to perform a "step climb" up to a higher level when it's more fuel-efficient than the current one. The flight levels are multiples of 2000ft for flights from the UK to the US, which is why the steps are 32000->34000?>36000ft.

    Wrapping up, one of the things I hoped to test by recording this journey was high rates of altitude change. The altitude logger can currently handle rates of change up to
  3. Like
    tripwire got a reaction from roadrunner84 in SensorTag Altitude Logger   
    Recently I took a trip to the US, which offered a good opportunity to test my altitude logger by recording a profile of the whole journey there. The trace revealed some interesting details about the flights I took, and airline operations in general.

    Here's the profile for the entire trip:
     

     
    The x-axis shows elapsed time in minutes. The altitude is shown in metres, measured relative to the start of the trace (not too far above sea level). Despite that I'll be using feet as the unit of altitude here, since that's the standard used in aviation. Because the logger calculates altitude based on air pressure, it is affected by cabin pressurisation. Instead of recording the true altitude of the aircraft it gives a trace of the effective altitude inside the cabin.

    The first big peak at the blue cursor is a flight from Edinburgh to London Heathrow. Comparing the cabin altitude trace against real altitude data makes it easier to pick out the main features, so here's a chart showing this flight's altitude as broadcast over ADS-B:
     

     
    And this is a closeup showing what my altitude logger recorded for the same flight:
     

     
    The cursors mark where I think the flight started and finished, based on the fact that the plane was in the air for 70 minutes. From takeoff the pressure falls steadily until the effective altitude in the cabin is about 7000ft, at which point the aircraft is actually at 37000ft. After cruising there for 12 minutes the plane descends and cabin pressure steadily increases.

    The cabin pressure reaches ground level before the plane actually lands, so the trace stays flat for the next 12 minutes. In fact, this section of the trace is effectively below ground level while the plane approaches landing. The plane's environmental control system has deliberately overshot and pressurised the cabin to higher than ambient pressure at the destination. At the orange cursor marking the end of the flight you can see a slight increase in altitude. This is when the flight is over and the controller opens the pressurisation valve to equalise with the external air pressure.

    It seems this extra pressurisation is done before takeoff and landing to help the system maintain a steady pressure. There's a detailed explanation of the reasons for this here: http://aviation.stackexchange.com/questions/16796/why-is-cabin-pressure-increased-above-ambient-pressure-on-the-ground

    Now on to the second flight, which was from Heathrow to Dallas Fort Worth. First the ADS-B trace:
     

     
    And the altitude logger's version of events:
     

     
    Again, the cursors mark the start and end of the flight and line up with the reported duration. The "steps" along the top of the trace match up with changes in cruise altitude from 32000?>34000?>36000ft. Maximum effective cabin altitude is about 5500ft, lower than the first flight even when the lower cruise altitude is taken into account. I think that's down to the use of a newer 777 on the international flight compared to the A319 on the domestic route. Modern planes are increasingly designed to offer lower effective cabin altitudes for passenger comfort.

    The stepped flight profile is used to maximise fuel efficiency. Flying higher reduces losses to air resistance, but early in the flight the aircraft is heavy with fuel and climbing is expensive. As the fuel is burned off the optimal cruise altitude increases, so ideally the plane would climb to match. In fact the plane can't climb gradually because modern air traffic control regulations restrict aircraft to set flight levels. The best option under these restrictions is to perform a "step climb" up to a higher level when it's more fuel-efficient than the current one. The flight levels are multiples of 2000ft for flights from the UK to the US, which is why the steps are 32000->34000?>36000ft.

    Wrapping up, one of the things I hoped to test by recording this journey was high rates of altitude change. The altitude logger can currently handle rates of change up to
  4. Like
    tripwire got a reaction from yosh in SensorTag Altitude Logger   
    Recently I took a trip to the US, which offered a good opportunity to test my altitude logger by recording a profile of the whole journey there. The trace revealed some interesting details about the flights I took, and airline operations in general.

    Here's the profile for the entire trip:
     

     
    The x-axis shows elapsed time in minutes. The altitude is shown in metres, measured relative to the start of the trace (not too far above sea level). Despite that I'll be using feet as the unit of altitude here, since that's the standard used in aviation. Because the logger calculates altitude based on air pressure, it is affected by cabin pressurisation. Instead of recording the true altitude of the aircraft it gives a trace of the effective altitude inside the cabin.

    The first big peak at the blue cursor is a flight from Edinburgh to London Heathrow. Comparing the cabin altitude trace against real altitude data makes it easier to pick out the main features, so here's a chart showing this flight's altitude as broadcast over ADS-B:
     

     
    And this is a closeup showing what my altitude logger recorded for the same flight:
     

     
    The cursors mark where I think the flight started and finished, based on the fact that the plane was in the air for 70 minutes. From takeoff the pressure falls steadily until the effective altitude in the cabin is about 7000ft, at which point the aircraft is actually at 37000ft. After cruising there for 12 minutes the plane descends and cabin pressure steadily increases.

    The cabin pressure reaches ground level before the plane actually lands, so the trace stays flat for the next 12 minutes. In fact, this section of the trace is effectively below ground level while the plane approaches landing. The plane's environmental control system has deliberately overshot and pressurised the cabin to higher than ambient pressure at the destination. At the orange cursor marking the end of the flight you can see a slight increase in altitude. This is when the flight is over and the controller opens the pressurisation valve to equalise with the external air pressure.

    It seems this extra pressurisation is done before takeoff and landing to help the system maintain a steady pressure. There's a detailed explanation of the reasons for this here: http://aviation.stackexchange.com/questions/16796/why-is-cabin-pressure-increased-above-ambient-pressure-on-the-ground

    Now on to the second flight, which was from Heathrow to Dallas Fort Worth. First the ADS-B trace:
     

     
    And the altitude logger's version of events:
     

     
    Again, the cursors mark the start and end of the flight and line up with the reported duration. The "steps" along the top of the trace match up with changes in cruise altitude from 32000?>34000?>36000ft. Maximum effective cabin altitude is about 5500ft, lower than the first flight even when the lower cruise altitude is taken into account. I think that's down to the use of a newer 777 on the international flight compared to the A319 on the domestic route. Modern planes are increasingly designed to offer lower effective cabin altitudes for passenger comfort.

    The stepped flight profile is used to maximise fuel efficiency. Flying higher reduces losses to air resistance, but early in the flight the aircraft is heavy with fuel and climbing is expensive. As the fuel is burned off the optimal cruise altitude increases, so ideally the plane would climb to match. In fact the plane can't climb gradually because modern air traffic control regulations restrict aircraft to set flight levels. The best option under these restrictions is to perform a "step climb" up to a higher level when it's more fuel-efficient than the current one. The flight levels are multiples of 2000ft for flights from the UK to the US, which is why the steps are 32000->34000?>36000ft.

    Wrapping up, one of the things I hoped to test by recording this journey was high rates of altitude change. The altitude logger can currently handle rates of change up to
  5. Like
    tripwire got a reaction from Fred in SensorTag Altitude Logger   
    Recently I took a trip to the US, which offered a good opportunity to test my altitude logger by recording a profile of the whole journey there. The trace revealed some interesting details about the flights I took, and airline operations in general.

    Here's the profile for the entire trip:
     

     
    The x-axis shows elapsed time in minutes. The altitude is shown in metres, measured relative to the start of the trace (not too far above sea level). Despite that I'll be using feet as the unit of altitude here, since that's the standard used in aviation. Because the logger calculates altitude based on air pressure, it is affected by cabin pressurisation. Instead of recording the true altitude of the aircraft it gives a trace of the effective altitude inside the cabin.

    The first big peak at the blue cursor is a flight from Edinburgh to London Heathrow. Comparing the cabin altitude trace against real altitude data makes it easier to pick out the main features, so here's a chart showing this flight's altitude as broadcast over ADS-B:
     

     
    And this is a closeup showing what my altitude logger recorded for the same flight:
     

     
    The cursors mark where I think the flight started and finished, based on the fact that the plane was in the air for 70 minutes. From takeoff the pressure falls steadily until the effective altitude in the cabin is about 7000ft, at which point the aircraft is actually at 37000ft. After cruising there for 12 minutes the plane descends and cabin pressure steadily increases.

    The cabin pressure reaches ground level before the plane actually lands, so the trace stays flat for the next 12 minutes. In fact, this section of the trace is effectively below ground level while the plane approaches landing. The plane's environmental control system has deliberately overshot and pressurised the cabin to higher than ambient pressure at the destination. At the orange cursor marking the end of the flight you can see a slight increase in altitude. This is when the flight is over and the controller opens the pressurisation valve to equalise with the external air pressure.

    It seems this extra pressurisation is done before takeoff and landing to help the system maintain a steady pressure. There's a detailed explanation of the reasons for this here: http://aviation.stackexchange.com/questions/16796/why-is-cabin-pressure-increased-above-ambient-pressure-on-the-ground

    Now on to the second flight, which was from Heathrow to Dallas Fort Worth. First the ADS-B trace:
     

     
    And the altitude logger's version of events:
     

     
    Again, the cursors mark the start and end of the flight and line up with the reported duration. The "steps" along the top of the trace match up with changes in cruise altitude from 32000?>34000?>36000ft. Maximum effective cabin altitude is about 5500ft, lower than the first flight even when the lower cruise altitude is taken into account. I think that's down to the use of a newer 777 on the international flight compared to the A319 on the domestic route. Modern planes are increasingly designed to offer lower effective cabin altitudes for passenger comfort.

    The stepped flight profile is used to maximise fuel efficiency. Flying higher reduces losses to air resistance, but early in the flight the aircraft is heavy with fuel and climbing is expensive. As the fuel is burned off the optimal cruise altitude increases, so ideally the plane would climb to match. In fact the plane can't climb gradually because modern air traffic control regulations restrict aircraft to set flight levels. The best option under these restrictions is to perform a "step climb" up to a higher level when it's more fuel-efficient than the current one. The flight levels are multiples of 2000ft for flights from the UK to the US, which is why the steps are 32000->34000?>36000ft.

    Wrapping up, one of the things I hoped to test by recording this journey was high rates of altitude change. The altitude logger can currently handle rates of change up to
  6. Like
    tripwire reacted to greeeg in CCSimpleLink   
    From my experience with the sensor tag it is for the CC26xx's only. The size limit comes from the compiler, and the ARM compiler used for the CC26xx's is completely different to the TI MSP430 compiler. For the MSP, GCC is always free and un-restricted. (but does create slightly larger binaries by nature.)
     
    There was no key for the sensor-tag, just installing the simplelink compiler comes with no size restrictions.
     
    [it's still slightly limited, in that it doesnt support the more expensive (and faster) debuggers, but works perfectly well with the onboard debugger of the launchpad itself.]
  7. Like
    tripwire got a reaction from Fmilburn in SensorTag Altitude Logger   
    Recently I took a trip to the US, which offered a good opportunity to test my altitude logger by recording a profile of the whole journey there. The trace revealed some interesting details about the flights I took, and airline operations in general.

    Here's the profile for the entire trip:
     

     
    The x-axis shows elapsed time in minutes. The altitude is shown in metres, measured relative to the start of the trace (not too far above sea level). Despite that I'll be using feet as the unit of altitude here, since that's the standard used in aviation. Because the logger calculates altitude based on air pressure, it is affected by cabin pressurisation. Instead of recording the true altitude of the aircraft it gives a trace of the effective altitude inside the cabin.

    The first big peak at the blue cursor is a flight from Edinburgh to London Heathrow. Comparing the cabin altitude trace against real altitude data makes it easier to pick out the main features, so here's a chart showing this flight's altitude as broadcast over ADS-B:
     

     
    And this is a closeup showing what my altitude logger recorded for the same flight:
     

     
    The cursors mark where I think the flight started and finished, based on the fact that the plane was in the air for 70 minutes. From takeoff the pressure falls steadily until the effective altitude in the cabin is about 7000ft, at which point the aircraft is actually at 37000ft. After cruising there for 12 minutes the plane descends and cabin pressure steadily increases.

    The cabin pressure reaches ground level before the plane actually lands, so the trace stays flat for the next 12 minutes. In fact, this section of the trace is effectively below ground level while the plane approaches landing. The plane's environmental control system has deliberately overshot and pressurised the cabin to higher than ambient pressure at the destination. At the orange cursor marking the end of the flight you can see a slight increase in altitude. This is when the flight is over and the controller opens the pressurisation valve to equalise with the external air pressure.

    It seems this extra pressurisation is done before takeoff and landing to help the system maintain a steady pressure. There's a detailed explanation of the reasons for this here: http://aviation.stackexchange.com/questions/16796/why-is-cabin-pressure-increased-above-ambient-pressure-on-the-ground

    Now on to the second flight, which was from Heathrow to Dallas Fort Worth. First the ADS-B trace:
     

     
    And the altitude logger's version of events:
     

     
    Again, the cursors mark the start and end of the flight and line up with the reported duration. The "steps" along the top of the trace match up with changes in cruise altitude from 32000?>34000?>36000ft. Maximum effective cabin altitude is about 5500ft, lower than the first flight even when the lower cruise altitude is taken into account. I think that's down to the use of a newer 777 on the international flight compared to the A319 on the domestic route. Modern planes are increasingly designed to offer lower effective cabin altitudes for passenger comfort.

    The stepped flight profile is used to maximise fuel efficiency. Flying higher reduces losses to air resistance, but early in the flight the aircraft is heavy with fuel and climbing is expensive. As the fuel is burned off the optimal cruise altitude increases, so ideally the plane would climb to match. In fact the plane can't climb gradually because modern air traffic control regulations restrict aircraft to set flight levels. The best option under these restrictions is to perform a "step climb" up to a higher level when it's more fuel-efficient than the current one. The flight levels are multiples of 2000ft for flights from the UK to the US, which is why the steps are 32000->34000?>36000ft.

    Wrapping up, one of the things I hoped to test by recording this journey was high rates of altitude change. The altitude logger can currently handle rates of change up to
  8. Like
    tripwire reacted to greeeg in Casio watch rebuild w/ MSP430   
    Source code is super simple, since the MSP debug stack is doing all the work.
     
    Just quickly compiled it on my PC, looks great! Just spits out a continuous stream of values, which you can pipe into a gnuplot etc.
     
    Turns your launchpad into a current sensor for any (3.6v only) application.
  9. Like
    tripwire got a reaction from jazz in Casio watch rebuild w/ MSP430   
    It looks like the author also made a tool to use EnergyTrace without needing to install CCS, might be worth a look:
     
    https://github.com/carrotIndustries/energytrace-util
  10. Like
    tripwire got a reaction from chicken in Casio watch rebuild w/ MSP430   
    It looks like the author also made a tool to use EnergyTrace without needing to install CCS, might be worth a look:
     
    https://github.com/carrotIndustries/energytrace-util
  11. Like
    tripwire got a reaction from spirilis in Casio watch rebuild w/ MSP430   
    It looks like the author also made a tool to use EnergyTrace without needing to install CCS, might be worth a look:
     
    https://github.com/carrotIndustries/energytrace-util
  12. Like
    tripwire reacted to chicken in Casio watch rebuild w/ MSP430   
    Today Hackaday featured someone that replaced the innards of a Casio watch with an MSP430FR6972
    http://hackaday.com/2016/05/30/gutting-and-rebuilding-a-classic-watch/

     
    Very well documented on GitHub, including more pictures:
    https://github.com/carrotIndustries/pluto
     
    If the author is on 43oh:
  13. Like
    tripwire reacted to curtis63 in MSP-EXP430FR5969 upgrade from 1.2 to 2.0. Can it be done ?   
    Ah!!!  Thank you everybody.  You are right.  I was looking above the JTAG socket and saw rev 1.2.  However, the board rev is 2.0 on my board as displayed on the upper right hand side of the board, as pictured in the post above.
     
    Thanks for clearing that up for me.  I really appreciate it !!
  14. Like
    tripwire reacted to greeeg in MSP-EXP430FR5969 upgrade from 1.2 to 2.0. Can it be done ?   
    I went and dusted off my old FR5969 boards.
     
    Here they are.

    From my memory they only ever sold the two? but maybe they have a newer one.
     
    The left one is the original with experimental silicon not intended for production use. After they released the production variant of the IC they removed this one entirely from the ezFET code, meaning you cannot debug/program it. The ezFET will still work fine programming external chips.
     
    You can check this quickly, the experimental silicon has X430 instead of MSP430.
     
     
    Secondly there are 2 model numbers for each PCB, the Launchpads them selves, 1.6 and 2.0. and then the ezFET 1.0 and 1.2.
     
    I very much doubt that mouser still has inventory of v1.6 launchpads with the ezFET 1.0, this was replaced by rev 2.0 with ezFET 1.2 about 2 years ago. TI even offered free replacement upgrades for everyone who bought them at the time.
     
  15. Like
    tripwire reacted to spirilis in Quad Thermocouple BoosterPack (MAX31855)   
    The full burn from start to finish (well, it's still simmering but only a few coals left, just enough to keep the downstairs room where the stove is located warm, which incidentally is also the makeshift vestibule where folks put on their socks & shoes before going outside):
     

     
    That overfire ticks me off because I should know better.  There's a compressed sawdust wood briquette product I use for my "endurance" fuel and it's dangerous to stack that stuff too high - it is super dense, burns very long, and up near the insulated ceramic baffles it'll burn uncontrolled since the secondary-combustion burn tubes have unlimited oxygen supply.  Typical light-density hardwood splits like poplar are OK up there because they're self-limiting - they shrink as they burn down and their coals don't last terribly long, but the wood briquettes swell as they burn (making the problem worse) and as I said, they are super dense, there's just a LOT of fuel there.  The inside of the burn tubes were glowing red and the whole baffle was glowing reddish-yellow in spots... The baffle can take it just fine, burn tubes (made of thick stainless steel) can take it too but will warp faster with that kind of usage (so instead of lasting 5-8 years, maybe a few less), but it's just more frightening than anything else.  Plus all the heat I wasted up the chimney!  Yargh.
     
    Quick pic taken during that episode, this is with the draft control (which adjusts primary air only) fully closed to the hard stop:

     
    The flames were so vigorous they were just shooting right into the glass and bouncing off.  Wish I had taken a video instead.  I have a lot of phrases for that situation, "gone nuclear" and "opened the gates of hell" come to mind ;-)
     
  16. Like
    tripwire reacted to zeke in Digital Ocean?   
    I've got my droplet up and running now.
     
    It felt good to dust off the linux admin skills and set everything up.
     
    Here's a screen shot of the speed comparison between my old and new service provider.
     

     
    That's the trigger point for me. Speed. And this is running on their $5/month configuration!
     
    I now like these new guys. Here's my referral link if anyone else wants to try out Digital Ocean for themselves.
     
     
    PS: @@bluehash, I encountered the dreaded myslq crash this morning. I've got it sorted out already. We should compare notes.
     
  17. Like
    tripwire reacted to phenyl in Analog Devices RF Detector Kit offer for $5   
    Well, I tried ordering two of the boards and a couple small tx modules.
    Luckily they sent me a mail asking if I accepted their shipping charge of 76.81 USD. (for a total of 31 USD of components)
     
    Which feels outrageous and so I politely declined...
    I chose "cheapest international shipping method", so for living out of the US it's simply out of any range of justification for a hobby purchase.
  18. Like
    tripwire reacted to grodius in TI OPT8241 Time of flight QVGA 3D sensor   
    It's more complex, but not too far removed from the Tindie for the ADNS-9800 laser mouse. Some bright enterprising spark might put together a hyper breakout. I'm mainly pleased that the early models are already very fast and high res.
     
    I personally really wish micromouse competitions forced the pros to use ONLY visual recognition and/or new tech. Micromouse comps are over-ripe slotcars now where sensor development and experimentation might be fun.
     
    It's worth just thinking about devices like these. I like the thought that you might only need one array receiver and maybe multiple light sources in sequence to triangulate or for redundancy/data improvement.
  19. Like
    tripwire reacted to Rickta59 in Question of memory and C++ object allocation   
    Just because you put the String object on the stack that doesn' t mean the managed string is on the stack.  In fact using the code above you end up making multiple calls to new (really malloc in Energias case)
    Breakpoint 1, setup () at /tmp/build7151962017509443788.tmp/sketch_may24a.cpp:2 2 void setup(); (gdb) b malloc Breakpoint 2 at 0xe6da: file ./stdlib/malloc.c, line 32. (gdb) c Continuing. Breakpoint 2, malloc (size=11) at ./stdlib/malloc.c:32 32 ./stdlib/malloc.c: No such file or directory. in ./stdlib/malloc.c (gdb) where #0 malloc (size=11) at ./stdlib/malloc.c:32 Reading 64 bytes from 0x02c0 #1 0x0000e2aa in String::changeBuffer (this=0x2f8, maxStrLen=10) at /mnt/vbox/shared/github/Energia/build/linux/work/hardware/msp430/cores/msp430/WString.cpp:159 #2 0x0000e2ec in String::reserve (this=0x2f8, size=<value optimized out>) at /mnt/vbox/shared/github/Energia/build/linux/work/hardware/msp430/cores/msp430/WString.cpp:150 Reading 8 bytes from 0xe7dc Reading 8 bytes from 0xe7e4 #3 0x0000e31a in String::copy (this=0x2f8, cstr=0xe7dc "0123456789", length=10) at /mnt/vbox/shared/github/Energia/build/linux/work/hardware/msp430/cores/msp430/WString.cpp:177 #4 0x0000e35e in String::String (this=<value optimized out>, cstr=<value optimized out>) at /mnt/vbox/shared/github/Energia/build/linux/work/hardware/msp430/cores/msp430/WString.cpp:33 #5 0x0000e098 in setup () at /tmp/build7151962017509443788.tmp/sketch_may24a.cpp:6 #6 0x0000e05a in main () at /mnt/vbox/shared/github/Energia/build/linux/work/hardware/msp430/cores/msp430/main.cpp:7 (gdb) c Breakpoint 2, malloc (size=1) at ./stdlib/malloc.c:32 32 in ./stdlib/malloc.c (gdb) c Breakpoint 2, malloc (size=5) at ./stdlib/malloc.c:32 32 in ./stdlib/malloc.c As you can see it made at least 3 calls to malloc 11 bytes, 1 byte, and 5 bytes.  The 11, 1, and 5 are requested by the String class.
     
    Although the String class data is going to be put on the stack, that only contains the meta data, like the buffer address, its capacity and len:
    (gdb) p this $5 = (const String * const) 0x2f8 String foo = {buffer = 0x240 "0123456789", capacity = 10, len = 10} The actual allocated buffer comes from heap managed memory, note the address of 0x240 which is much lower address than the address of the String foo metadata living at 0x2f8.  The malloced data represents the actual buffer content length plus a null terminator byte. So 11 bytes 10+1 null and 5 bytes (4 + 1 null).  In the string class the line:
     
    String out; 
     
    ends up allocating 1 byte because an initial value isn't provided so it defaults to "" + null.
     
    In all honesty, you want to avoid using the String class as it is going to eventually fragment memory and fail.  It is a horrible thing to use on chips with hardly any memory.
     
    -rick
     
    BTW: Here is the test code I used:
     
  20. Like
    tripwire got a reaction from greeeg in TI OPT8241 Time of flight QVGA 3D sensor   
    The 2nd generation Kinect that shipped with the Xbox One uses time of flight to calculate depth. There's a nice summary of the method here: http://www.gamasutra.com/blogs/DanielLau/20131127/205820/The_Science_Behind_Kinects_or_Kinect_10_versus_20.php. It also explains the structured light system used in the original Kinect and compares the pros and cons of each system.
     
    Regarding the sensor and controller being separate chips, I think that may be unlikely to change. The sensor is made using a "chip on glass" process which I suspect isn't ideal for the controller. Also, keeping the controller off the sensor die avoids any problems with it heating the sensor (which would increase the noise level).
     
    EDIT: About 30 seconds after posting this I found the OPT8320, which does integrate the controller and framebuffer memory into a single CoG package. That one's only 80x60 pixels, however.
  21. Like
    tripwire got a reaction from spirilis in Question of memory and C++ object allocation   
  22. Like
    tripwire got a reaction from oPossum in Question of memory and C++ object allocation   
  23. Like
    tripwire got a reaction from chicken in TI OPT8241 Time of flight QVGA 3D sensor   
    The 2nd generation Kinect that shipped with the Xbox One uses time of flight to calculate depth. There's a nice summary of the method here: http://www.gamasutra.com/blogs/DanielLau/20131127/205820/The_Science_Behind_Kinects_or_Kinect_10_versus_20.php. It also explains the structured light system used in the original Kinect and compares the pros and cons of each system.
     
    Regarding the sensor and controller being separate chips, I think that may be unlikely to change. The sensor is made using a "chip on glass" process which I suspect isn't ideal for the controller. Also, keeping the controller off the sensor die avoids any problems with it heating the sensor (which would increase the noise level).
     
    EDIT: About 30 seconds after posting this I found the OPT8320, which does integrate the controller and framebuffer memory into a single CoG package. That one's only 80x60 pixels, however.
  24. Like
    tripwire reacted to spirilis in G2553 and i2c slave   
    No.  Because the "static" keyword is there, this only happens once, at the very beginning of program start.  This is what makes the "static" keyword special in the context of a function (in addition to the fact that it informs the compiler to allocate the variable outside the function's ephemeral stack space).
     
    Note that in the global context, i.e. outside of a function, "static" means something totally different.  Yay C!
  25. Like
    tripwire reacted to spirilis in Question of memory and C++ object allocation   
    I think it depends on whether right is meant to be inclusive or not.  I suspect it's not meant to be inclusive, hence why it works this way.  So the substring comprises left to (right-1).  That's pretty common in other programming languages IIRC.
×
×
  • Create New...