Jump to content
43oh

tripwire

Members
  • Content Count

    193
  • Joined

  • Last visited

  • Days Won

    14

Reputation Activity

  1. Like
    tripwire reacted to Fred in 4 x 6 cm Projects   
    I'd say the main (perhaps only) reason for making your own PCBs is if you enjoy it. Whilst in theory I could make a board in a couple of hours, it would take me 2 weeks to find those spare hours!
  2. Like
    tripwire reacted to enl in 4 x 6 cm Projects   
    Main reason for messing with CNC is no wait. Photo-resist etching, same thing. The drawbacks to both of these is the mess and the limitation to double-sided boards and no through plating.
     
    Sourcing from a commercial shop in China is days to weeks, depending on quantity, complexity, destination, and holidays.
     
    Quality of a commercially made board is likely to be higher, and generally has the bells and whistles of solder mask and screenprinting, but when you need it tomorrow, or today, you sometimes even go as far a sharpie and that sludgie bottle of Ferric Chloride that has been sitting in the cabinet since 1987. This is why I miss my pen plotter. Draw the board. Etch the board. Back in the plotter with a fine point to label the board. Assemble.
  3. Like
    tripwire got a reaction from Rei Vilo in [FIXED!] JTAG interferes with SensorTag external flash access   
    Good news! This issue is fixed in the TI Emulators 6.0.228.0 package, which contains the version 2.3.0.1 firmware for XDS110.
     
    TI have added support for 2-wire cJTAG debugging, which only uses the TMS and TCK lines. In the 2.3.0.1 firmware they also stopped the emulator from driving TDO, which was blocking access to the SPI. It looks like 2-wire cJTAG is the default mode now too, so debugging SPI flash code should just work like you'd expect.
  4. Like
    tripwire got a reaction from zeke in [FIXED!] JTAG interferes with SensorTag external flash access   
    Good news! This issue is fixed in the TI Emulators 6.0.228.0 package, which contains the version 2.3.0.1 firmware for XDS110.
     
    TI have added support for 2-wire cJTAG debugging, which only uses the TMS and TCK lines. In the 2.3.0.1 firmware they also stopped the emulator from driving TDO, which was blocking access to the SPI. It looks like 2-wire cJTAG is the default mode now too, so debugging SPI flash code should just work like you'd expect.
  5. Like
    tripwire reacted to Rickta59 in TI not supporting MSP-EXP430G2 on Mac or Linux?   
    They made the decision early on.  It seems at some point they actually told people instead of keeping it quiet. I guess they hadn't decided.  Back in 2012 it was a miracle to even have linux support.  At that time all they said was: "The LaunchPad is not supported on Linux at this time." To me the implication was they might in the future.
     
    https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/171173/688729#688729
     
    I can't find the thread where they finally said they would never support it but they did say it at one point.
     
    [edit] I found the post .. from 2015 [/edit]
    https://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/171173/1712768#1712768
  6. Like
  7. Like
    tripwire reacted to Fmilburn in would Window 10 installation affect my sketch work developed using Energia 11?   
    Hi @@retiredee72
     
    There are too many variables to answer that with assurance. If you do a search on 43oh you will find a few posts from people who had problems with the transition to Windows 10 (and frquently the solution). Personally I found Energia to work better with Windows 10 and have had no problem with CCS.
  8. Like
    tripwire reacted to chicken in Chrome for portable UI development (serial, USB)   
    Here's a tutorial on programming a graphical UI in Google Chrome to display data received over serial
    http://www.lucadentella.it/en/2016/06/07/chrome-app-e-comunicazione-seriale/
    via Dangerous Prototypes.
     
    I meant looking into this topic for a long time. For serial communication like in this tutorial, but also USB for a portable upgrade application via a custom USB BSL implementation.
     
  9. Like
    tripwire reacted to LIJsselstein in Have feedback for TI? Please share here.   
    I've started this week using CCS to debug and analyse power consumption of my battery powered device using the Energia framework. CCS/EnergyTrace is a powerful tool when it works, however, I have one really really annoying problem with it: debugging does not work most of the time.
     
    When it works, pressing the debug button will break the code on the first line in setup() and EnergyTrace is running during debug. When it doesn't work, the device seems to be running and debugging seems to run, but it won't stop in setup() or other breakpoint I set, Pauze button is greyed-out and EnergyTrace is not working. Stopping and starting debug many times will eventually lead to a functional debug session but it may take 10+ attempts. I've tried removing the debug configuration, restarting CCS, powercycling the launchpad....
     
    Nothing seems to help consistently, but detaching/attaching during debug and then performing a soft reset is most consistent to resolve the breakpoint problem for one debug session, but then EnergyTrace still does not work.
     
    There are no errors in the console. CCS 6.1.1 is completely up to date. Windows 7 Pro x64. FET on FR6989 launchpad used for programming G2553 device.
  10. Like
    tripwire reacted to dubnet in Have feedback for TI? Please share here.   
    Looks like they may have incorporated one of the suggestions. TI store now shows free shipping on orders over $150. Threshold is a little higher than I'd like to see, but a nice step in the right direction.
  11. Like
    tripwire reacted to swampdonkeykami in [Group Buy-19][O] TMS0803/5 Emulating Calculator With Bubble Display   
    "@swampdonkeykami  Thank you for the review!"
     
    You may be mistaking me for somebody with an obscure youtube channel. 
  12. Like
    tripwire got a reaction from yosh in MSP432 launchpad as programmer...?   
    I've done this little mod on a MSP432 launchpad so I can program the CC2650 SensorTag with it (and use energytrace too).
     
    The 1x7 0.05" headers aren't the easiest to get hold of, so I just took a standard 10-pin cortex debug cable, cut it in half and soldered it directly to J103. The connections needed are (LP -> Cortex debug connector):
     
    GND -> GNDDetect (pin 9)
    RST -> nRESET (pin 10)
    SWCLK -> SWDCLK/TCK (pin 4)
    SWDIO -> SWDIO/TMS (pin 2)
    3V3 -> VTref (pin 1)
     
    Pin 1 is marked by the red stripe on the cable linked above. Apart from making sure to read the pin numbers the right way round, the only fiddly bit is crossing over the GND and reset wires in limited space.
     
    The ribbon enters the connector opposite the key at one end and next to it at the other. It's worth checking both halves of the cable to see which gives the best cable routing for your target board.
     
    To test you can remove the jumpers from the isolation block and set the JTAG switch to external, then connect the cable to the Ext Debug header on the launchpad and try to program the MSP432 target.
  13. Like
    tripwire got a reaction from spirilis in MSP432 launchpad as programmer...?   
    I've done this little mod on a MSP432 launchpad so I can program the CC2650 SensorTag with it (and use energytrace too).
     
    The 1x7 0.05" headers aren't the easiest to get hold of, so I just took a standard 10-pin cortex debug cable, cut it in half and soldered it directly to J103. The connections needed are (LP -> Cortex debug connector):
     
    GND -> GNDDetect (pin 9)
    RST -> nRESET (pin 10)
    SWCLK -> SWDCLK/TCK (pin 4)
    SWDIO -> SWDIO/TMS (pin 2)
    3V3 -> VTref (pin 1)
     
    Pin 1 is marked by the red stripe on the cable linked above. Apart from making sure to read the pin numbers the right way round, the only fiddly bit is crossing over the GND and reset wires in limited space.
     
    The ribbon enters the connector opposite the key at one end and next to it at the other. It's worth checking both halves of the cable to see which gives the best cable routing for your target board.
     
    To test you can remove the jumpers from the isolation block and set the JTAG switch to external, then connect the cable to the Ext Debug header on the launchpad and try to program the MSP432 target.
  14. Like
    tripwire reacted to yyrkoon in Nodejs GPIO   
    The thing is, there are a number of SBC's out there that can do as good of, or even a better job - Potentially. I think the rPI 3 *could* be a better option. But again, it really depends. How many of why type of input peripherals are needed ? Board cost of the rPI3 is also less, but one does need to purchase an sdcard separately. However, the rPI3 also has 4 host USB ports, and built in wifi / bluetooth 4.x that the beaglebone does not have. There are also many aspects of the Beaglebone that trump the rPI3, but I'm not sure those aspects would come into play here. But in the capacity of operating as a computer( server, etc ), the rPI3 also is the better board.
     
    So again, I think it all comes down to how much of what type of peripheral one needs . . .
     
    As an example of why the Raspberry PI 3 is a better board when operating as a general purpose computer( running an OS ). I recently compiled Nodejs on both the Beaglebone black, and the Raspberry PI3. The Beaglebone took 3.5 hours to compile from source while the Raspberry PI took around 1 hour 15 minutes. So obviously the rPI3 has more computational power, as well as twice as much memory. So if you think twice as much memory is no big deal . . . think again. Thats twice as much memory that can be used as a ram disk, which can be an important factor on an embedded system. As flash media has limited write cycles where DDR does not. So one can have a read only file system for the rootfs, and use a RAM DISK overlay for changing data.
  15. Like
    tripwire got a reaction from dubnet in MSP432 launchpad as programmer...?   
    I've done this little mod on a MSP432 launchpad so I can program the CC2650 SensorTag with it (and use energytrace too).
     
    The 1x7 0.05" headers aren't the easiest to get hold of, so I just took a standard 10-pin cortex debug cable, cut it in half and soldered it directly to J103. The connections needed are (LP -> Cortex debug connector):
     
    GND -> GNDDetect (pin 9)
    RST -> nRESET (pin 10)
    SWCLK -> SWDCLK/TCK (pin 4)
    SWDIO -> SWDIO/TMS (pin 2)
    3V3 -> VTref (pin 1)
     
    Pin 1 is marked by the red stripe on the cable linked above. Apart from making sure to read the pin numbers the right way round, the only fiddly bit is crossing over the GND and reset wires in limited space.
     
    The ribbon enters the connector opposite the key at one end and next to it at the other. It's worth checking both halves of the cable to see which gives the best cable routing for your target board.
     
    To test you can remove the jumpers from the isolation block and set the JTAG switch to external, then connect the cable to the Ext Debug header on the launchpad and try to program the MSP432 target.
  16. Like
    tripwire reacted to grodius in Working with MPU6050 on MSP430   
    Just a discussion point, I think the motivation to pair an MSP430 with an MPU6050 is justified based on the Invensense hype and PR that all the heavy lifting would be handled by the magical DMP onboard coprocessor. In the real world, the gyro and acc data is very noisy and filter and calibration dependent. It's a really useful experiment to play with as it broke some of my theoretical idealism with the reality that sensors are super noisy. Getting the best and fastest possible orientation from this device will be a combination of filtering the raw data and combining data. It really felt like every 6050 was different, so the chances the filtering and IMU combination being optimal in the DMP feels iffy, but I would try and see.
     
    My personal recommendation is to fire up a 2452 launchpad with the terrific I2C explorer from this forum and have a play with what you can get back from the sensor documentation. I then modified the I2C explorer to a binary serial connection and did all my tinkering in a java app to get an understanding of the sensor under movement without constantly flashing a device.
  17. Like
    tripwire reacted to zeke in What is "our" time worth ?   
    It think it's good to practice The Engineering Craft even when it's only for myself.
     
    Sometimes, it's the compulsion to create something beautiful that motivates me. Othertimes, it's personal pleasure. In the case of my Marquee Clock project, I am working on that clock for the pleasure of seeing my daughter's reaction to it. She's my client.
     
    Personal projects are like workouts. They give me a reason to exercise my skills so that I can see how effective I am right now.  I can then explore, experiment and improve how I implement various solutions.
     
    Ultimately, practice makes perfect.
  18. Like
    tripwire reacted to yyrkoon in What is "our" time worth ?   
    @@zeke @@dubnet and everyone really
     
    I'd be curious for others input as to how often they actually know 100% of the work they're contracted to do, before they start the job. I often find myself doing a LOT of research on, and off the job. So in essence in some respects I get paid as a troubleshooter. Which I might add I'm usually very good at.
     
    Anyway, I suppose I could charge more per hour, but this is partially why I charge only what I charge for an hourly flat rate. But another aspect is that I often "take my work home", or work after hours off the clock just because I want to be informed, and perhaps I find what I'm researching fascinating . . .
  19. Like
    tripwire reacted to dubnet in What is "our" time worth ?   
    @yyrkoon   That's exactly what I allude to in my comments on a post mortem evaluation.  You have to tally all the time and be brutally objective.  Of course, some off clock time needs to be spent staying current on your craft and managing the back end of the business.  But the off clock time creep on projects can seriously erode your income. 
     
    EDIT:  Rereading your post prompts the question....Are you charging the client for the research as well?
  20. Like
    tripwire reacted to dubnet in What is "our" time worth ?   
    Having been at this for over 20 years I have found that setting a rate can be part art, part science.  Obviously it depends on a lot of factors (e.g. type of market, competitors, value delivered, customer perception of value delivered, etc.). Like @@Fmilburn mentioned in an earlier post, in the end the rate needs to strike a fair balance between the buyer and seller.
     
    Long ago I had an acquaintance who provided similar services to mine. He constantly complained about mistreatment/disrespect from his customers, with a good number who hadn't paid him.  His rate was less than half of what I charged. When he asked what he could do about it I advised him to significantly increase his rate which would do two things. It would scare off the customers looking for the lowest possible cost (the same ones that didn't pay and typically were the most problematic/difficult customers). It would also create a perception of value with the remaining customers as long as he was delivering value commensurate with his rate.  Unfortunately, he didn't heed the advice. His business faltered and he now works for someone else.
     
    One of the things I have done in the past, if entering a new market, is to assess what competitors that provide similar services as we do charge for their services. Provided there are enough of them in the market to yield enough data points to be meaningful, I can position our services at a price point that reflects both the marketplace as well as the unique value we provide in the context of that marketplace. However, in the end I probably still don't charge enough.
     
    One caveat though, after looking at the market rate, is if all your competitors are living in the back of their vans your cost structure may kill you.  Even after arriving at a market rate you still have to look at all your costs, both hard costs and your time. I have found that doing a post mortem on projects, where you have tracked every minute of your time (billable and non billable), can be a real eye opener in terms of your "real" (now diluted) hourly rate.  With this information you can determine if what you are providing to the market will be truly fruitful to you or not.
  21. Like
    tripwire reacted to spirilis in I'm struggling with the CC3200   
    @@zeke
    On the topic of TI-RTOS, for which I am slowly drinking the koolaid droplet by damned droplet .... I highly recommend starting HERE: http://rtsc.eclipse.org/docs-tip/RTSC_Module_Primer
     
    Once you've wrapped your head around RTSC XDC, TI's old excuse-for-not-using-C++-by-inventing-an-OOP-layer-on-top-of-C-probably-ancient-from-the-old-days-when-C++-compilers-were-unstable-or-didn't-exist-even-though-shit's-different-now-and-they-should-just-scrap-the-damned-thing-and-use-C++-in-earnest-but-I-get-it-I-really-do-they-just-have-too-much-time-and-effort-invested-in-it-to-give-it-up-oh-and-many-professional-embedded-developers-still-don't-trust-C++, much of the TI-RTOS components start to make a little bit of sense.
  22. Like
    tripwire reacted to spirilis in TI Store Happy Geek Pride Day! Celebrate with discounted shipping.   
    Almost way too overpowered, and the dev environment is a bit unconventionally restrictive - you have to use HALCoGen to generate projects and CCS for the coding/building/debugging.  Not too bad for folks already comfy with the CCS toolchain et al, but it's still quite esoteric.  Probably 99% of hobbyist projects have no need for the power too... although there's a "Jan Cumps" on twitter from Belgium who's adopted the Hercules as his pet MCU of choice for giggles.
     
    This is all mostly due to its "safety critical" nature, which shapes everything about how TI supports it.  TI's own TI-RTOS (aka SYS/BIOS aka DSP/BIOS) doesn't even support it, they include project generation for FreeRTOS for those who want an RTOS on the chip.  FreeRTOS does have safety critical "support" via their SafeRTOS variant.
     
    OTOH the fact they have an all-in-one project generation tool that supports all the peripherals including the fascinating custom-VLIW instruction set "HET" timer is a bit envy-worthy; most TI MCUs just don't have such an "all in one" configurator.
     
    Anyway I recommend you roll with it regardless!  There's probably a lot of cool stuff you can do with those with the right motivation.
  23. 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
  24. Like
    tripwire got a reaction from Fmilburn in BoostMP3 LauchPad BoosterPack   
    I like the idea of making it compatible with the kentec touchscreen boosterpack, but stacking one of those above your board would block access to the buttons. If instead used with the onboard OLED display or headless you'd have pushbuttons immediately next to a set of upward pointing male boosterpack headers.
     
    Have you thought about using right-angle tactile switches pointing off the edges of the board? TI has just started to use them on their launchpads: http://www.ti.com/ww/en/launchpad/launchpads-connected-launchxl-cc2650.html#tabs
  25. Like
    tripwire reacted to chicken in BoostMP3 LauchPad BoosterPack   
    You guys are a though crowd today
     
    Fist of all, Herzlich Willkommen auf 43oh @@mathiasbuder
     
    I don't think that comparing this project to an off-the-shelf MP3 player is useful, comparing to an Android tablet even less so. A customer for this BoosterPack will buy it as a tool to experiment and build their own contraptions (e.g. a radio clock?).
     
    MP3 shields for Arduino are a more relevant comparison:
    Adafruit sells their Music Maker shield for $30, based on the same IC but seems to have a lot less functionality (no recording, no buttons, no optional display). Sparkfun's MP3 Player Shield is $25, again only audio out. Seeed's Grove Serial MP3 Player is $15, again no recording. There are shields on Ebay for around $10 that support recording, e.g. this one. But software support is probably much worse than with Adafruit et al.  
    So your price may be a bit high compared to the competition, even when accounting for the superior functionality. On the other hand, there's nothing like this for TI LaunchPads yet, so there can be a markup within reason. The higher the price the more you will have to justify it with very good support with beginner friendly libraries (Energia) and documentation.
     
    Given the small TI LaunchPad ecosystem, I wouldn't expect a lot of sales, even at a lower price point. Sales will most likely be driven by publishing interesting projects based on your BoosterPack that others want to replicate. Think Hackaday, Instructables, etc.
     
    My final advice after selling a few hundred of my own widgets: Don't under-price yourself. Making and selling hardware takes a lot of time and money. When your little side project happens to be a success and turns into serious work, it is important that it will pay for your expenses and then some. If it doesn't sell because it was too expensive, you at least learned something and had fun doing so (just don't fabricate 100's of them upfront).
     
    Ignoring the business side, I still think it's a nice project. I have an older version of that MP3 chip sitting in my drawer since 10+ years and never came around actually putting it to good use.
×
×
  • Create New...