ilmenator

A little update: out of curiosity I defragmented the SD card. The effect is that now my data is corrupted, when I read it from the SD card using my MIOS app (and subsequently write it to an SRAM card). The first sector is okay, after that something is wrong (I can't say exactly where the mess starts, the Wavestation I use to verify the SRAM prog card with resets itself when a sound with a higher memory location is selected). I guess that there is something wrong with the pointers to the next sector / cluster? This is handled differently in the MIOS driver and Win?

von Ploytec

Sounds like a browser setting?

Using that tool I can read blocks of sectors. I can identify those sectors that contain the original SRAM data (that is the data written by my MIOS application). I can not find the data originally saved using the computer (that is the data that still shows using Explorer and opening the file!) - though I have to admit that I did not search through the whole SD card as NTDiskViewer only writes "00" into the file when I try to read the whole card at once. Chunks of 16MB are okay, but my SD card is roughly 900MB in size... I also removed the card reader to really make sure no cache is involved. I'm afraid I have to re-partition the SD card again to make it more friendly to handle. Did that. The SD card is now 24MB in size. It behaves the same as before. I cannot read on a Win XP computer what my MIOS app has written on the card. The files are shown in Win Explorer, but they contain what was originally in them when I created them in Win. A bin copy of the complete SD card shows that the data written by my MIOS app nevertheless is there on the card - I just cannot access it properly. ???

Siehe auch hier, Punkt 3): es wird von Ploytec multi-client fähige Treiber für das GM5 Modul geben. Die funktionieren dann auch nur mit dem Chip auf dem GM5 Modul. Die Standard-Betriebssystem-Treiber tun es auch, sind aber nicht multi-client fähig.

Okay, I'm back home and did some more testing. Strangeness remains, though... 1) I do eject the device. No cache involved. 2) I created a .syx (well, actually I renamed one of my test files with known content). I ran TK's sysex_overwriter and looked at the file on my PC again. The content has not changed. The sysex_overwriter did not give me an error message, though. 3) I do use the SDCARD_FILE_Seek(offset) function to determine the sector before each 512byte sector read in my own code. Is there a way to tell (on Win XP) which clusters are used by a specific file? If I compared that with sdcard_file_cluster I could probably see clearer. PS: napierzaza, look here

I see that Elproma also have branches in the Netherlands and Belgium. Given the prices that koki quotes, maybe users in these countries (as well as koki) could try to get a quote on the quantities that stryd has collected?

Hi all, I managed to use my SD card as file storage for synth bank sounds. I can read SRAM program cards (32kB is a common size) and write their content to a file on the SD card. I can also read the file back and store it in that SRAM. All this is fine, but some problems remain. I only discovered that this is actually working more or less by accident... Here are my questions: 1) If I read the documentation of the sdcard module correctly, then I have to create a file on the SD card in my computer first and can then write to that file. I cannot create a new file from the MIOS application, correct? 2) As all my files will have the same size (32kB), this is not a problem. The strange thing is that on my computer (a Win XP system) I create the file and fill it with some content, eg. all "FF". Then I overwrite it with the SRAM program card content. Now, when I read the file again from SD card on my computer, it still contains all "FF". But I can nevertheless read the SRAM program card content correctly from that same file in my MIOS app. This means that although the filenames are identical, MIOS and Windows access different sectors of the SD card. Huh? 3) My SD card was originally a 4GB card. What I did to make it work was to partition it to around 900MB using gparted-live-0.3.7-7, and then format it FAT16 with sector size 512 bytes in Win XP. Is this okay? So, my SD card suffers from schizophrenia. ;D Did I say that any help would be appreciated? Thanks, ilmenator

You have to login with your forum user name and password. Then you modify an existing page, by setting a link to a new (non-existing) page. When you try to follow that link, the wiki will notice the page does not exist and will ask you if it should be created. Choose yes, and you have a new wiki page.

I can confirm that the above schematic is actually correct, my card seems to be working now. The problem apparently was that I am using the floppy cable connector as shown below - you have to be careful not to push the card too far into the connector, otherwise contact will not be made. It's a bit fragile, but for a first try okay - if you know about the difficulties, that is ;). Note that only two of the diodes are actually used - the other two are bridged on the backside, so the circuit is exactly as shown in the schematic above. Also, when the card is correctly inserted, the voltage is 3.6V which apparently works without damaging the card. Btw, the card is partitioned to 1GB so that FAT16 can be used (the full 4GB can not be used). Best regards, ilmenator SD-Card.JPG SD-Card_reverse.JPG

Not nice enough, though :(. Attached is the schematic that I use to connect the SD card. The cable to the core goes like this: K1-1: J7 RC K1-2: J7 SC K1-3: J7 SO K2-4: J7 Vd K2-6: J7 Vs K4-7: J6 SI (I am counting the pin numbers of the SD card as shown in the SD footprint PNG). When I load the "dir_browser" example application, all I get is error code 01, which apparently means "0x01 Error during SD Card Access (SDCARD_SectorRead or SDCARD_SectorWrite)". Although I am using 1N4148 diodes, the voltage drop across these seems to be considerably smaller than 0.7V each - I measure around 4.2V at VDD33 of the SD card... which might be related to the low current that the SD card needs. Anyway, I am a little afraid of killing my SD card. So far it is still working... So, what could be wrong here? TK, can you confirm that this is the schematic that you use? Thanks, ilmenator SD-Card.PNG SD-Conn.PNG

Okay, I think I know how the schematic TK uses looks like. Apparently, judging from the photos he posted, it is very similar to this, which is basically the same as published by U. Radig here. All the sources I found on the net are extremely similar :). I'll see if I can find these components in my spare parts box :D.

Possibly yes. Although the shape looks perfectly like the other buttons, so the mold was not affected. It's more like with these knobs the amount of black pigments is slightly reduced.

I received two of those! ;D (Actually, it's a really, really small difference in color that you only notice in good light. Also, the transparency is slightly different, which you only notice when looking at the knob from below.)

Thorsten, I checked the repository but could not find any reference to the schematic / hardware you used to interface the SD card. Can you provide us with that, so I can really try the SD card module? Best regards, ilmenator

I want to have a limited edition extra rare knob as well ;D

Good work! Looks like there is heaps of hot glue on the IIC modules - what for?

1T.16 is rectangular shaped, which means you'll need to invest more money to get a decent front panel. 1U.16 seems to be a rather attractive (even better, IMHO) alternative to the 1D.16 caps. It is also round shape but with a slight curvature on top (instead of the bevel found on the 1D.16). So yes, I'm interested ;D Best regards, ilmenator

I'm definitely interested in that, yes. Though I will have only limited space on my front panel, especially the "height" of the PCB needs to be as small as possible (well, as small as reasonable...). Also, I've been searching for these three-legged 3mm LEDs for quite some time without success. All I could find was the 5mm version - I suppose these don't fit the MEC switches, right? Best regards, ilmenator

Silently lurking here because I'm still unsure about quantity. It will most probably be something like this: 50 pcs. 3FTL6 "Quiet" 40 pcs. 1D.16 (Translucent white) xx pcs. 1S11.16.0 (Clear cylindrical) Best regards, ilmenator

The second pair arrived today - clear and purple, very nice :D. Thanks a lot, again - and excellent packaging, btw! Best regards, ilmenator

Now that's a good remark, stryd - I had not noticed this before.

If you are unsure how to solder in the 100µF capacitor, you could try to leave it out in the first place. There are three reasons why I suggest this: 1) You seem to be a beginner and the cap is an addition to the original board design, so there are no holes for it on the board. Makes things slightly more difficult (not much, though). 2) With the 100µF capacitor, the board becomes really ugly and clumsy. No visual joy. 3) None of the six or more DOUT boards I have built over time actually required this capacitor. They all work flawlessly without it. If you experience any problems with the board, you could still add the 100µF cap at a later time. Best regards, ilmenator

I bought from them twice - once shipping to Germany, once to Norway. No additional emails from my side, not a single problem with them. The last order was around May this year (shopping for verrry cheap LED bars for my stribe). Best regards, ilmenator

Hi all, I have created a struct that holds status information which is 2 bit wide, each: // status of menu typedef union{ struct { unsigned MENU:16; }; struct{ unsigned MENU_MODE:2; unsigned MENU_LEVEL:2; unsigned SOURCE_BANK_TYPE:2; unsigned MENU_ACTION:2; unsigned DEST_BANK_TYPE:2; }; } volatile menu_flags_t; Now, I need to analyse these states, and I would like to use a switch command to increase readability: // status of menu (see declaration in main.h) menu_flags_t menu_flags; // call functions that depend on menu level switch(menu_flags.MENU_LEVEL){ // menu level 1: case 1: switch(pin){ case DIN_INC: .... case DIN_DEC: .... case DIN_ENTER: .... } break; // menu level 2: case 2: // menu_level == 2 switch(pin){ case DIN_INC: .... case DIN_DEC: .... } break; Unfortunately, the compiler complains: main.c:316: warning 94: comparison is always true resp. false due to limited range of data type main.c:316: warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG Line 316 is the one with the first switch command. So how to do it correctly? Or is switch a No-No with bitfields? Thanks, ilmenator