Hawkeye

Administrators
  • Content count

    3,340
  • Joined

  • Last visited

Community Reputation

58 Excellent

2 Followers

About Hawkeye

  • Rank
    MIDIbox Guru
  • Birthday 01/15/1976

Contact Methods

  • Website URL http://www.youtube.com/user/Maelstroem3

Profile Information

  • Gender Male
  • Location Germany, Munich

Recent Profile Visitors

8,032 profile views
  1. IMG_0014.jpg

    Nice job! That is a heck of a modiphyed v4+! :)
  2. Troubleshooting midiphy SEQ v4+

    @SimonSays fantastic, well done & congratulations! Many greets, Peter
  3. Troubleshooting midiphy SEQ v4+

    @SimonSays can you measure the connectivity of the PWR 5V and GND pins of the waveshare board to the wCore board (the two bottom-right pins in Andy's picture above)? If you have inserted and removed the waveshare board from the wCore PCB a lot of times, there might be bad conductivity between gold pinheaders and the header sockets on the wCore, if some headers are bent to the side (this "pinbending" can happen after forceful "uneven" removal of the waveshare board, when you lift one side quicker than the other). If you measure "fluctuating connectivity" (i.e. the continuity beeper beeps when you push down on the USB socket, and does not otherwise), you could just solder top to bottom bodge wires to connect the pins respectively. I've seen something like that happen once, when the gold pin headers of the waveshare board were bent a little bit after too many removals/reattachments of the waveshare board. It also requires quite some force to push it fully in, please measure if the standing height of the wCore/waveshare board assembly is just below 20mm (e.g. by using the provided four 20mm hexspacers), so it sits flat on your table, then it is ok. Many greets and good luck! Peter
  4. Troubleshooting midiphy SEQ v4+

    @SimonSays indeed, that should not happen! But: could you check the settings of the switches on the waveshare board? The power switch should be set to "5V in" - if it is wrong (e.g. accidentally changed it during the measurements), that could explain, why the core is unresponsive! https://www.youtube.com/watch?v=QaN26uzUA1A&t=3362s Many greets, Peter
  5. midiphy SEQ v4+

    @secrethero303 correct, the easiest way to go for "red/cyan" is to connect a single resistor from A to 1 (red) and single resistor from B to both 2 and 3 (blue+green mix). (Note: this shortcut driving 3 "logical" LEDs with only 2 resistors only works, because green and blue have very similar diode forward voltages, so current flows through both, if there was a bigger difference, most current would flow through one of the LEDs not resulting in a color mix) So, for better blue/green hue control, it might be better if you use two individual resistors going from B to 2 and from B to 3. Also, within limits, you can experiment with resistor values other than 47R to achieve a better color mix. While the resulting peak current (only during the duty cycle, average current is much lower) is officially out of "superflux specs" (and we don't support it), you might go down to 22R resistors as a minimal testing value, like this you could find an improved color mix, for example (untested!): A <- 47 R -> 1 (normal red brightness) B <- 22R -> 2 (increased green brightness) B <- 56R -> 3 (lowered blue brightness) -> resulting in cyan with a hue shift towards green Modern LeMEC boards have two holes for individual resistors at insertion point B, but you can also solder a "fork" at a single "B" insertion point, if there is only one - that should be easy. In my personal opinion, the superflux LEDs can withstand 22Rs, as they are operated only in a 1/8 duty cycle, BUT - this is out of specs and we do not encourage lower resistors than 47R from our side - while it worked for me, your mileage may vary and you might burn them up for good. If that happens, you know where to find replacements! :) As Andy knows, i had some great fun abusing a few of mine while looking for new color combinations! ;-) Many greets and have fun! Peter
  6. Troubleshooting midiphy SEQ v4+

    @SimonSays R33D should be ok - please also check connectivity of all datalines - from the problematic J15 port to the waveshare board (through the headers) - some years ago, i had a display with similar garbage and one data line was disconnected. You might also want to reflow the pins of the waveshare headers (on the wCore PCB) before measurements, just to try that out before you measure a lot of pins. If it still does not work after reflowing, measurement from J15 to the waveshare core MCU and then to the STM32F4 IC pins are the only way to check for continuity (quite some work!). Also check for "neighboring" unwanted shorts, as those could well cause the problem, too. I'd recommend to reflow every pin first, especially as reflowing on R33D seems to have helped! Many greets, Peter
  7. Questions about using STM32F4 for v1.4

    Should work! MIDIbox FM 1.4 supports the PIC18F4685. Many greets and have fun! Peter  
  8. Troubleshooting midiphy SEQ v4+

    @SimonSays wild guess, but maybe bridged "E" lines? E.g. on the waveshare board headers? Could you upload hi-res photos of the front and backside of your wCore PCB? Have you pushed in the waveshare board all the way? The wCore with installed waveshare board must be able to stand on 20mm hex standoffs, if the assembly is higher, the waveshare board is not pushed in fully. Many greets, Peter
  9. DSA clears: spider-approved!

    Oh dear, what a beast! ;-)
  10. Questions about using STM32F4 for v1.4

    Hi Theo, The classic MIDIbox FM 1.x is only available for the older 8bit core and written in pure PIC assembly and thus not super easily portable to the new STM32F4s. @Sauraen did a great job of porting, but his version is the only one known to work on modern cores. In short: you need an old core, sorry! :) Many greets, Peter
  11. Great job! It is also always nice to see MIDIboxes during public gigs! Many greets, Peter
  12. Multiple projects side by side

    @tago it depends on your preferred workflow, personally i would not recommend to move anything at all outside of git, as you will lose the benefits of having an integrated code version control system, i.e. you could look at any time what you have modified locally and you can perform local commits that are not pushed back to the server while you work on your personal projects. I'd see two options: a) you could just work within your fully cloned repository tree b) i have not done it, but it might be possible to clone the main tree (library) somewhere, point your environment variables to it, so the build process works and clone the respective app subdirectories somewhere else (if this works, i think i read about "sparse checkouts" somewhere). This would allow you to work more like you describe on an individual app/project level within a separate directory structure but with full git benefits, if you prefer that. If this does not work, you could just create logical filesystem links, if you are working in a unix environment? With both variants you can perform local commits, which is useful for development. If you work from multiple local machines like a laptop and a desktop you could also setup a server system like "gitea" and enable pushing to a central server by adding a new origin - that works nicely and you would then have a local tool like "github" at home, including browser based diffs and all the bells and whistles :). Many greets and have fun! Peter
  13. Multiple projects side by side

    @tago trying to free up time for TK a bit here, if what i am saying is wrong, he will surely correct me: With libraries, the intention is to have more or less "stable" interfaces, that multiple apps can rely on. Defining the interface at first is why it is so difficult to create them :). You would need to define a  "minimal" (non over-engineered) interface at first and try to only extend it over time. If you need to change a core api function call signature, all dependencies have to be updated, that's why this should be avoided and i think this is excatly what Thorsten does. So, from an "app implementors viewpoint", you'd only need to check out everything once, and work on the "app level", use the MIOS library as far as possible. If the library does not provide for what is needed, you can extend it internally within your app. If that extension results in a function that you think will be useful for other users, you could extend the library itself and create a pull request for Thorsten to evaluate your addition to his code. The idea is always to avoid overengineering, an API that is too vast is often distracting, complex to understand and will make development harder. Hopefully this was correct and helpful! Best regards, Peter
  14. Elrom Teaser :)

    @FantomXR we love backlit matias switches! :)
  15. Cool review and great gear for portability! Many greets! Peter