Interface Seeburg wall box to empeg

Posted by: techtom

Interface Seeburg wall box to empeg - 15/07/2007 07:46

I'm trying to interface a seeburg walllbox http://tomszone.com/3W1.html into an empeg. I think I pretty much figured out the logic but I had a few questions:

I plan on compling an arm app to run on the player. How do I add it to the start up script? (e.g. rcS)

I plan on sending the hxxp://empeg/?NODATA&SERIAL=%23FID%2b command to quenue songs. Is there and easier way? I would prefer just to dump the command to a /proc file

I can use empeg_notify to determine the state of the player. But is there and easier way to find out if the empeg has finished the playlist?

Can I use the tuner serial port to receive seeburg commands?

Ideally, It would be nice if I could insert my app as a shim between the serial port and the player app.

ideas?

Thanks,

-Techtom
Posted by: mlord

Re: Interface Seeburg wall box to empeg - 15/07/2007 11:42

Quote:
I plan on compling an arm app to run on the player. How do I add it to the start up script? (e.g. rcS)


Add it to /empeg/var/config.ini as follows:

[hijack]
;@EXEC_ONCE some command of yours

Quote:

I plan on sending the <a href="hxxp://empeg/?NODATA&SERIAL=%23FID%2b" target="_blank">hxxp://empeg/?NODATA&SERIAL=%23FID%2b</a> command to quenue songs. Is there and easier way? I would prefer just to dump the command to a /proc file


I think the same thing is doable as follows, or something very close to this:

echo 'SERIAL=#FID+' >/proc/empeg_notify

Quote:

I can use empeg_notify to determine the state of the player. But is there and easier way to find out if the empeg has finished the playlist?


Define, programmatically, "finished the playlist". Note that the empeg merely pauses at the end of a playlist. Pressing "Play" starts it up again. You could screen scrape the "end of playlist" message, though.
Quote:

Can I use the tuner serial port to receive seeburg commands?


Possibly. But I think there's actually a *third* serial port on that connector(?) also. Use it instead.

Cheers
Posted by: mlord

Re: Interface Seeburg wall box to empeg - 15/07/2007 12:03

Quote:
Quote:

Can I use the tuner serial port to receive seeburg commands?


Possibly. But I think there's actually a *third* serial port on that connector(?) also. Use it instead


Mmmm... Pin-7 at the tuner connector is an (unused) I2S signal line. Which means it's a serial line of some kind. I dunno where it terminates on the mainboard, though.

Cheers
Posted by: mlord

Re: Interface Seeburg wall box to empeg - 15/07/2007 12:15

Quote:
Quote:
I plan on sending the <a href="hxxp://empeg/?NODATA&SERIAL=%23FID%2b" target="_blank">hxxp://empeg/?NODATA&SERIAL=%23FID%2b</a> command to quenue songs. Is there and easier way? I would prefer just to dump the command to a /proc file


I think the same thing is doable as follows, or something very close to this:

echo 'SERIAL=#FID+' >/proc/empeg_notify



Yup, that works, as in:

echo 'SERIAL=#211+' >/proc/empeg_notify
Posted by: techtom

Re: Interface Seeburg wall box to empeg - 15/07/2007 17:24

Quote:

Quote:

I can use empeg_notify to determine the state of the player. But is there and easier way to find out if the empeg has finished the playlist?


Define, programmatically, "finished the playlist". Note that the empeg merely pauses at the end of a playlist. Pressing "Play" starts it up again. You could screen scrape the "end of playlist" message, though.




The problem is that if you send #FID+ to a player that is at the end of the playlist, it will not play. You'd need to send <space>. but then the player will replay the whole playlist with the added song at the end. For "jukebox" like opperation, you need to perform the following test:

read empeg_notify:
if notify_FidTime = "0:00:00"; // empeg might be starting a new tune/playlist or paused
wait 2 seconds and read empeg_notify again
if notify_FidTime = "0:00:00"; // empeg is paused
send #NewFID
else (from first if) ;// empeg is playing
send #NewFID+

The above logic should work fine, but It has to wait at least one second to see if the player is paused.

Thanks for your help,

-Techtom
Posted by: techtom

Re: Interface Seeburg wall box to empeg - 15/07/2007 17:29

Quote:

Mmmm... Pin-7 at the tuner connector is an (unused) I2S signal line. Which means it's a serial line of some kind. I dunno where it terminates on the mainboard, though.



I don't think I can use pin-7 because I2S is a serial audio bus format (the format CD players send to the D/A converter). It probably terminates in the DSP. Does your kernel support/initialize three uarts?

-Techtom
Posted by: mlord

Re: Interface Seeburg wall box to empeg - 15/07/2007 19:47

Quote:

The problem is that if you send #FID+ to a player that is at the end of the playlist, it will not play. You'd need to send <space>. but then the player will replay the whole playlist with the added song at the end. For "jukebox" like opperation, you need to perform the following test:

read empeg_notify:
if notify_FidTime = "0:00:00"; // empeg might be starting a new tune/playlist or paused
wait 2 seconds and read empeg_notify again
if notify_FidTime = "0:00:00"; // empeg is paused
send #NewFID
else (from first if) ;// empeg is playing
send #NewFID+

The above logic should work fine, but It has to wait at least one second to see if the player is paused.


There is a field in /proc/empeg_notify that is a simple 0/1 value for paused/playing. I think it's called "sound" or something like that.

Cheers
Posted by: mlord

Re: Interface Seeburg wall box to empeg - 15/07/2007 19:49

Quote:
Quote:

Mmmm... Pin-7 at the tuner connector is an (unused) I2S signal line. Which means it's a serial line of some kind. I dunno where it terminates on the mainboard, though.



I don't think I can use pin-7 because I2S is a serial audio bus format (the format CD players send to the D/A converter). It probably terminates in the DSP. Does your kernel support/initialize three uarts?



Yeah, it must go to the DSP then. The main SA1100 CPU has three serial ports configured: one for the back panel, one for the tuner, and another for the I/R transceiver (not the remote control, the *other* I/R that's unused).

To use the tuner serial port, some extra hackery will be needed inside the kernel to isolate your use of it from that of the player software and Hijack. Perfectly doable, and as you surmised it's likely the only solution that can be done without hardware hackery.

Cheers
Posted by: tfabris

Re: Interface Seeburg wall box to empeg - 15/07/2007 22:02

Quote:
I'm trying to interface a seeburg walllbox http://tomszone.com/3W1.html into an empeg.


Absolutely brilliant idea. Wow.

Since the keypad has letters A-F, you could even just do four-digit FIDs directly... was that your plan?
Posted by: techtom

Re: Interface Seeburg wall box to empeg - 16/07/2007 00:20

Quote:

Absolutely brilliant idea. Wow. Since the keypad has letters A-F, you could even just do four-digit FIDs directly... was that your plan?


No. To keep it simple the Wallbox works as is. The wall box sends pulses to indicate the buttons pressed. They are always a letter number pair. I plan on using an off the shelf $99 pulse to rs232 converter from http://www.cdadapter.com/pcplay.htm I don't have it yet so I don't have all the interface details worked out.

The emplayer app is very simple. Start it with a playlist fid (e.g. Seeburg 0x1151). The app listens on the tuner rs-232 port and recieves the button press "G3". the app looks up the 73rd FID entry in the playlist. The app checks notify_Sound value, if zero send #FID else send #FID+

The FID entry in the play list can be a tune or another playlist. So the Seeburg can start either one from a single button press.

I figure i can keep it simple if I just use an rs232 interface...

However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)

-Techtom

Here's a ethernet version of the same thing... http://www.bengtson.org/seeburg/ He also has more details on the pulse interface
Posted by: tfabris

Re: Interface Seeburg wall box to empeg - 16/07/2007 01:07

Quote:
recieves the button press "G3". the app looks up the 73rd FID entry in the playlist.

Aha. That'd work, too, and wouldn't require updating some kind of second list on an intermediary device. All you'd need to do is make sure the playlist is ordered correctly. OK, I'm with ya.

Quote:
However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)


I seem to recall that the PCA version of the tuner module deliberately included some general purpose I/O lines that you might be able to mess with. If you happened to have one of those. If not, then you're not really saving the 99.00 because then you'd have to buy a PCA tuner.
Posted by: mlord

Re: Interface Seeburg wall box to empeg - 16/07/2007 01:37

Quote:

However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)


There are several GPIO lines attached to the rear-panel DB-9 connector (serial port). The "headlight sense" line is a good candidate, as it is not normally used for anything when operating on AC power.

That's serial port pin-8 (CTS).
Also possible, is the telephone mute input, on serial port pin-1 (CD).

Cheers
Posted by: techtom

Re: Interface Seeburg wall box to empeg - 16/07/2007 02:25

Quote:
Quote:

However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)


There are several GPIO lines attached to the rear-panel DB-9 connector (serial port). The "headlight sense" line is a good candidate, as it is not normally used for anything when operating on AC power.

That's serial port pin-8 (CTS).



Great! I assume that there is no memory manager on the empeg. So I should be able to read it from a Volatile char pointer right? What's the address & Bit #?

Another question, for a "hello world" app, What are the correct gcc-arm-linux flags to generate a statically linked app?

Thanks,

Techtom
Posted by: mlord

Re: Interface Seeburg wall box to empeg - 16/07/2007 09:31

Quote:
Quote:
Quote:

However, the ideal way to do it (and save $99) would be to find a single GPIO input pin that the app could read. The app would listen for the pulses and count them to determine the buttons pressed. Any suggestions as to what gpio to use? (e.g one that I can read from user space)


There are several GPIO lines attached to the rear-panel DB-9 connector (serial port). The "headlight sense" line is a good candidate, as it is not normally used for anything when operating on AC power.

That's serial port pin-8 (CTS).



Great! I assume that there is no memory manager on the empeg. So I should be able to read it from a Volatile char pointer right? What's the address & Bit #?

Another question, for a "hello world" app, What are the correct gcc-arm-linux flags to generate a statically linked app?



The empeg uses Linux as the O/S, which is a protected memory operating system. So, yes, it has a memory manager.

Use the source.

Cheers
Posted by: tonyc

Re: Interface Seeburg wall box to empeg - 16/07/2007 20:01

Quote:

Another question, for a "hello world" app, What are the correct gcc-arm-linux flags to generate a statically linked app?



arm-empeg-linux-gcc object1.o object2.o -Wl,-Bstatic $(STATIC_LIBS) -Wl,-Bdynamic $(DYNAMIC_LIBS) -o $@
Posted by: mlord

Re: Interface Seeburg wall box to empeg - 16/07/2007 20:29

Quote:
Quote:

Another question, for a "hello world" app, What are the correct gcc-arm-linux flags to generate a statically linked app?



arm-empeg-linux-gcc object1.o object2.o -Wl,-Bstatic $(STATIC_LIBS) -Wl,-Bdynamic $(DYNAMIC_LIBS) -o $@


I generally just do: arm-empeg-linux-gcc -static file.c

Cheers
Posted by: techtom

Next steps (was Re: Interface Seeburg wall box to empeg) - 19/07/2007 22:34

Quote:

I generally just do: arm-empeg-linux-gcc -static file.c

Cheers


I've looked at the kernel and analyzed the seeburg pulse train. It looks like I can use the system timer to sample the CTS/headlight line and "read" the seeburg pulses.

I'll add a small/fast amount of code to the reset_timer (SA1100/time.h) routine. every tick I'll check to set if the seeburg line (CTS) has gone low. if it has, I'll have the code log the OSCR register and CTS bit for the next 250 ticks into a small buffer(250*4). Once 250 ticks have been collected, the buffer is flagged as ready and the code returns to waiting for the seeburg line to go low.

A simple charater driver will retrive the OSCR tick buffer and make it available in userspace. The userspace app will parse the time stamps, determine the button press, index the playlist and queue the FID.

w.r.t building the kernel, I noticed in menuconfig that loadable module support is not enabled. Does the Hijack kernel support loadable modules? Can I just turn it on and recomple the kernel? When I build a new kernel, can I boot it without burning it to flash? If I have to burn it to flash, what's the de-brick proceedure?

Thanks,

-Techtom
Posted by: mlord

Re: Next steps (was Re: Interface Seeburg wall box to empeg) - 20/07/2007 00:00

Quote:

w.r.t building the kernel, I noticed in menuconfig that loadable module support is not enabled. Does the Hijack kernel support loadable modules? Can I just turn it on and recomple the kernel? When I build a new kernel, can I boot it without burning it to flash? If I have to burn it to flash, what's the de-brick proceedure?



Loadable modules should work, but we don't have them enabled by default -- no need, and module support takes up precious memory (DRAM).

We don't have a proper software bootloader setup, so testing kernels currently requires burning them to flash. The de-brick procedure is simple: just burn another kernel over top of the failed one! Zero risk.

Cheers
Posted by: techtom

Re: Next steps (was Re: Interface Seeburg wall box to empeg) - 21/07/2007 01:11

Status: Installed tools, built kernel, flashed via ftp empeg +50 times, seeburg driver working, /dev/wallbox returns 256 samples.

The driver seems to be working and I'm getting the timestamps. But I had a question about blocking reads in a device... What is the correct way to block (wait for input) in a device?

The interrupt routine increments "samples_collected", but the driver needs to wait until 256 samples have been collected.

Is there some sort of kernel mutex I set in the interrupt routine and wait on in the driver?

Thanks,

-Techtom


here's the read part of the driver:
Code:

ssize_t
seeburg_read (struct file * filep, char *buff, size_t count, loff_t * offp)
{
/* function to copy kernel space buffer to user space */
if (samples_collected == MAX_SAMPLES && tick_tock==0)
{
if (copy_to_user (buff, pulse_samples, sizeof (pulse_samples)) != 0)
{
printk ("Kernel -> userspace copy failed!\n");
}
printk ("samples collected %d\n", samples_collected);
samples_collected == 0;
tick_tock = 1;
return sizeof (pulse_samples);
}
return 0;
}

Posted by: mlord

Re: Next steps (was Re: Interface Seeburg wall box to empeg) - 21/07/2007 09:02

Quote:
What is the correct way to block (wait for input) in a device?

The interrupt routine increments "samples_collected", but the driver needs to wait until 256 samples have been collected.

Is there some sort of kernel mutex I set in the interrupt routine and wait on in the driver?



There are other ways, but one of the simplest is to use a semaphore:

Code:


struct semaphore mysem = MUTEX_LOCKED;

...

// Interrupt handler:

if (++count == desired_number)
up(&mysem); /* signal that data is available */

...

// mainline driver's read() or ioctl() routines:
...
down(&mysem); /* wait for data */
...



Note that these are "counting" semaphores, so you could even get clever with them if you want, but the simple form above will work.

Cheers
Posted by: techtom

Re: Next steps (was Re: Interface Seeburg wall box to empeg) - 22/07/2007 04:52

Quote:
There are other ways, but one of the simplest is to use a semaphore:



Got it. thanks for the tip.

Next question. I was planning to use the DTR output as the pullup resistor +5V source. But it looks like it's deasserted (-5V). Most rs-232 DTEs assert DTR. I can turn it on in my driver, but is it used for something else?

Thanks,

-Techtom

Status: the driver and the ISR are returning good samples. So the kernel work is finished. I've parsed/plotted the samples collected on my empeg by the driver in excel (see attached). Now the hard part... need to write the user program to parse the samples and extract the button codes...
Posted by: mlord

Re: Next steps (was Re: Interface Seeburg wall box to empeg) - 24/07/2007 00:11

Cool.

I'm on holiday (beaches) for the next couple of weeks.. offline and all of that.

Cheers!
Posted by: techtom

It works! - 25/07/2007 06:51

Thank's to Mark's help, I've succeeded, it works!!!

The seeburg is connected to pin 8 (CTS) of the empeg serial port. A kernel driver (/dev/wallbox) and a user app (wallbox) convert the pulses to a fid in the "seeburg" playlist. The selected fid is added to the currently playing list.

Here's a sample output from the serial port:
Code:

empeg:/empeg/bin# /wallbox 1ad0 &

seeburg open: state 1
Read 100 items from playlist 1ad0
.
empeg:/empeg/bin# player
Timezone: PRC
Hijack: intercepting config.ini
player.cpp : 385:empeg-car 2.00-beta13 2002/07/24.
Prolux 4 empeg car - 2.1434 Jul 24 2002
Vcb: 0x4086d000
.
Selection E3 is fid 2a0
#2a0
.
Selection H6 is fid 2b70
#2b70+
.
Selection K6 is fid 690
#690+
.
Selection J9 is fid 45a0
#45a0+



I need to clean up the code and I've got some questions that hopefully someone can answer in Mark's absence...


1. I was planning to use the DTR output as the pullup resistor +5V source. But it looks like it's deasserted (-5V). Most rs-232 DTEs assert DTR. I can turn it on in my driver, but is it used for something else?

2. I'm currenly using fprintf(empeg_notify_fp,"SERIAL=#fid\n") to queue the song. But I was thinking of using the "write" portion of my driver to "notify" the Hijack kernel directly. I've looked at notify.c, but I'm not sure which function to call.

3. I'm using down(&sem) but I'd like to use down_interrruptable. When I do, I get an unresolved external. I #include <asm-arm/semaphore.h> but it doesn't help.

4. What's the best licence to release under (e.g. BSD)?

5. I'd like to release the code, but I probably need some sort of "code review" for my kernel / driver changes. Can anyone help out?

6. How do I pick a "real" device MAJOR number?

Thanks,

-Techtom
Posted by: peter

Re: It works! - 25/07/2007 15:30

Just in case you weren't fully aware of the fact, this is exceptionally cool! Do we get a photo gallery somewhere about it?

I once had a coffee (but no cherry pie) at a diner in Philadelphia that still had an installation of those things. Though I think theirs was original, not Empeg-powered...

Peter
Posted by: petteri

Re: It works! - 25/07/2007 19:09

Yes, this is a great project! Hell, I want to see a video of this in action!
Posted by: techtom

Seeburg Wallbox -- Video Demo - 26/07/2007 04:16

Quote:
Yes, this is a great project! I want to see a video of this in action!


As requested, here's a link to the demo of my seeburg wallbox interface.


http://www.youtube.com/v/f3Z31FvUHMo

Code:

This is a demonstration of a program I wrote to interface a
Seebug 3W-100 wallbox to an empeg mp3 player. Below is
the text that was on the computer screen. It shows the
wallbox app startup and the button selections.
.
empeg:/empeg/bin# /wallbox &
[1] 147
empeg:/empeg/bin#
seeburg open: state 1
Read 100 items from playlist a7d0
.
empeg:/empeg/bin# player
Timezone: PRC
Hijack: intercepting config.ini
.
player.cpp : 385:empeg-car 2.00-beta13 2002/07/24.
Prolux 4 empeg car - 2.1434 Jul 24 2002
Vcb: 0x4086d000
.
.
samples collected 256
state is 4
empeg_sound is 0
.
.
Selection F10 is fid 31f0
#31f0
samples collected 256
state is 4
empeg_sound is 1
.
.
Selection C4 is fid 2a70
#2a70+



-Techtom
Posted by: Roger

Re: Seeburg Wallbox -- Video Demo - 26/07/2007 06:43

Quote:
As requested, here's a link to the demo of my seeburg wallbox interface.


Sweet.
Posted by: petteri

Re: Seeburg Wallbox -- Video Demo - 26/07/2007 08:14

Good stuff!
Posted by: LittleBlueThing

Re: Seeburg Wallbox -- Video Demo - 26/07/2007 13:27

Fantastic!!!!

It's going to look funny on the dash though
Maybe in a pink cadillac?
Posted by: tfabris

Re: Seeburg Wallbox -- Video Demo - 26/07/2007 16:23

Absolutely fucking brilliant.

Awesome.
Posted by: cushman

Re: Seeburg Wallbox -- Video Demo - 26/07/2007 16:34

Very, very cool! Good work!

Now how about a Seeburg wallbox group buy?
Posted by: tanstaafl.

Re: Seeburg Wallbox -- Video Demo - 26/07/2007 19:47

Quote:
demo of my seeburg wallbox interface.


Impressive!

I noticed one absolutely trivial discrepancy. I'm not criticizing, just curious: When you skipped to the second track, the time stamp showed the track starting at 2:14, instead of 0:00, even though it was actually the beginning of the song.

Is this fixable, even though it doesn't really need to be?

tanstaafl.
Posted by: tfabris

Re: Seeburg Wallbox -- Video Demo - 26/07/2007 20:19

Is it possible that he had the time display mode set to "Count down"?

And in any case, that wasn't *his* display, that was the now-and-next display built into the empeg player software, he can't change that. If there's a bug related to that, it's far too late to fix it now.
Posted by: tfabris

Re: Seeburg Wallbox -- Video Demo - 26/07/2007 20:23

Ah, I see. He had the time display set to "Playlist elapsed/Total". It's working correctly.

It starts off with his first song entry being a song of 2:14 in length. Then he enqueues a second song, thus making the total playlist time be over four minutes. When he presses "Next" to advance to the second song, the time index starts at 2:14 because it's the playlist position (the end of the 2:14 song).
Posted by: gbeer

Re: Seeburg Wallbox -- Video Demo - 26/07/2007 22:58

Quote:
Absolutely fucking brilliant.

Awesome.


tfabris, you are fined one credit for a violation of the verbal morality statute.
Posted by: mlord

Re: It works! - 01/08/2007 09:51

Quote:

1. I was planning to use the DTR output as the pullup resistor +5V source. But it looks like it's deasserted (-5V). Most rs-232 DTEs assert DTR. I can turn it on in my driver, but is it used for something else?


I think it is available. The docking connector uses CTS for "headlight", and CD for "telephone mute", but DTR seems to have no non-standard (RS232) use.

Quote:

2. I'm currenly using fprintf(empeg_notify_fp,"SERIAL=#fid\n") to queue the song. But I was thinking of using the "write" portion of my driver to "notify" the Hijack kernel directly. I've looked at notify.c, but I'm not sure which function to call.


The implementation of "SERIAL=" itself calls hijack_serial_rx_insert(the_string, strlen(the_string, 1)), where the_string must include a trailing '\n' (newline).

Quote:

3. I'm using down(&sem) but I'd like to use down_interrruptable. When I do, I get an unresolved external. I #include <asm-arm/semaphore.h> but it doesn't help.


That's weird. down_interruptible() is a kernel inline function, so it doesn't really exist at run/link time. Don't even thing about declaring it with a function prototype or extern line. The correct include file is asm/semphore.h, but if that's not working for you, then you could try including asm/proc/semaphore.h before it.

Quote:

4. What's the best licence to release under (e.g. BSD)?


You have no choice for the kernel module: GPLv2. For the rest, LGPL or GPL are both good (IMHO). With full souce code released, BSD is also decent.

Quote:

5. I'd like to release the code, but I probably need some sort of "code review" for my kernel / driver changes. Can anyone help out?


Just release it, and anyone who cares will eventually have a peek at it. That's the whole idea for open source stuff!


Quote:

6. How do I pick a "real" device MAJOR number?


It varies, depending upon the kernel version. For the empeg kernel, the simplest is to just re-use an existing one that never had meaning on an empeg. But there is some documentation for your exact question in the Documentation/devices.txt file from the kernel source tree.

Cheers!
Posted by: techtom

Seeburg release in progress... - 02/08/2007 20:28

Quote:

... DTR seems to have no non-standard (RS232) use.



I've looked at serial_sa1100.c It looks like they have ifdef/removed DTR support from the serial driver. I could re-implement the DTR functionality (e.g flush before de-asserting DTR, etc), but I'm just planning on asserting DTR when port 1 is opened.

Quote:

The implementation of "SERIAL=" itself calls hijack_serial_rx_insert(the_string, strlen(the_string, 1))



Yup, found that too. I'll call it directly. Thanks. I noticed that when I write to empeg_notify, I need to send "+" as "%2B". When I call rx_insert directly, Can I send "#FID+\n" or do I still need to send "#FID%2B\n"?

Quote:

That's weird. down_interruptible() is a kernel inline function, so it doesn't really exist at run/link time.



Yes it is wierd... <asm-arm/semaphore.h> actually has the inline definition of down_interruptible. There's probably some #define that's turning it off...

Quote:

Just release it, and anyone who cares will eventually have a peek at it.


How exactly do I release the kernel part? I'm using v459 patched to v461 (serial bug v441 fixes). are you willing accept it into the hijack source tree? I'd need the latest source tarball which I would provide diff -c patch files. Most of the work is done in reset_timer (timer.h) and in my seeburg.c driver. Small changes in notify.c, mem.c and serial_sa1100.c (DTR). I can also create a menuconfig item in arch/arm/config.in to turn on/off seeburg driver support.

Quote:
Quote:

6. How do I pick a "real" device MAJOR number?


For the empeg kernel, the simplest is to just re-use an existing one that never had meaning on an empeg. [See] Documentation/devices.txt file from the kernel source tree.



Ok I'll use 51 (Baycomm radio modem in devices.txt)

Thanks for all your help!

-Techtom
Posted by: mlord

Re: Seeburg release in progress... - 02/08/2007 21:38

Quote:
I noticed that when I write to empeg_notify, I need to send "+" as "%2B". When I call rx_insert directly, Can I send "#FID+\n" or do I still need to send "#FID%2B\n"?

Do the same as you did when writing to /proc/empeg_notify.

Quote:

How exactly do I release the kernel part?

You could start by posting it here as an attachment. Then I can have a look-see and decide how best to incorporate it into Hijack (based mostly on code size, compatbility, etc..).

Cheers
Posted by: music

Re: Seeburg Wallbox -- Video Demo - 03/08/2007 20:32

Quote:
tfabris, you are fined one credit for a violation of the verbal morality statute.


I never did get the hang of using those shells.

Enhance your calm, Glenn Spartan.

Posted by: techtom

Re: Seeburg Wallbox release, Attached - 07/08/2007 05:56

Quote:
Quote:

How exactly do I release the kernel part?

You could start by posting it here as an attachment. Then I can have a look-see and decide how best to incorporate it into Hijack (based mostly on code size, compatbility, etc..).




Mark,
Attached is my driver for the Seeburg Wallbox. It consists of two files (attached). The sampler runs in linux/include/asm-arm/arch-sa1100/time.h and the driver is in a separate file seeburg.c

I also made the following small changes in three files (in pseudo diff -c)
Code:

file:drivers/char/serial_sa1100.c line 2342
.
#ifdef SERIAL_DEBUG_OPEN
printk("rs_open %s%d, count = %d\n", tty->driver.name, info->line,
info->state->count);
#endif
+ //hack -- force on DTR because driver doesn't
+ if(line==1)
+ GPDR &= ~EMPEG_SERIALDTR;
+ //hack-end
.
.
.
file /drivers/char/mem.c line 699
.
extern void empeg_cs4231_init(void);
extern int empeg_power_init(void);
+ extern int seeburg_init(void);
+ seeburg_init();
#ifdef CONFIG_EMPEG_RAMTEST
.
.
.
file: arch/arm/special/notify.c line 40
.
#define NOTIFY_FIDLINE 2 // index of 'F' in notify_chars[]
+#define NOTIFY_SOUNDLINE 6 // index of 'S' in notify_chars[]
#define NOTIFY_MAX_LENGTH 64
static char notify_data[NOTIFY_MAX_LINES][NOTIFY_MAX_LENGTH] = {{0,},};
.
+const char *notify_sound (void)
+{
+ return &notify_data[NOTIFY_SOUNDLINE][0];
+}

Posted by: techtom

Re: Seeburg Wallbox release, Attached - 07/08/2007 05:58

Seeburg.c driver attached

(time.h is attached in the previous post)
Posted by: mlord

Re: Seeburg Wallbox release, Attached - 07/08/2007 11:29

Quote:
Seeburg.c driver attached


It seems to be missing an interrupt handler or some such thing, where the up(&seeburg_sem) line lives.

EDIT: oh, nevermind. That part was buried in the prior attachment.

Could you perhaps just create a proper unified patch instead,
by running this command (below) to differentiate between an original
Hijack kernel tree and your modified kernel treee?

diff -u --recursive --new-file hijack-v477/ seeburg/

Posted by: techtom

Re: Seeburg Wallbox release, Attached - 07/08/2007 14:46

Quote:

Could you perhaps just create a proper unified patch instead,
by running this command (below) to differentiate between an original
Hijack kernel tree and your modified kernel treee?

diff -u --recursive --new-file hijack-v477/ seeburg/




Sure. How do I change the directory name and have buildit still work? I ask because I patched v459 to v461 but when I tried to rename the directory to v461 the build complained about not being able to find files based off the v459 path.

Do I need to patch to the current v477 or can I do the diff -u on my unmodified v461 tree?

-Techtom
Posted by: mlord

Re: Seeburg Wallbox release, Attached - 07/08/2007 16:08

Quote:

Do I need to patch to the current v477 or can I do the diff -u on my unmodified v461 tree?



A diff against v461 (but not v460) should be new enough for this purpose, so just diff what you've got.

The buildit script was just my own personal convenience hack.

Cheers
Posted by: techtom

Re: Seeburg Wallbox release, Attached - 07/08/2007 22:58

Quote:

A diff against v461 should be new enough for this purpose, so just diff what you've got.



As requested... One of two attachments.

-Techtom
Posted by: techtom

Re: Seeburg Wallbox release, Attached - 07/08/2007 22:59

Quote:

A diff against v461 should be new enough for this purpose, so just diff what you've got.



As requested... Two of two attachments. This patch is for time.h only. It looks like I ran "indent" on the time.h file after I added my code. Thats why there are alot of changes in the patch. All "real" changes are confined within the #ifdef MAX_SAMPLES.

-Techtom

Edited to change attachment to cleaner version of the patch
Posted by: mlord

Re: Seeburg Wallbox release, Attached - 08/08/2007 00:31

Quote:

As requested... Two of two attachments. This patch is for time.h only. It looks like I ran "indent" on the time.h file after I added my code.


Ghad. Could ya maybe do it again with the -b flag then ?

I really just want to see what you did, not what was cumulatively there since 1991 or so.

Thanks.
Posted by: techtom

Re: Seeburg Wallbox release, Attached - 08/08/2007 01:44

Quote:

Could ya maybe do it again with the -b flag then ?



Here ya go...

-Techtom
Posted by: techtom

Re: Seeburg Wallbox release, time.h patch for V477 - 12/08/2007 03:43

I've attached my latest patch for time.h. The previous time.h patch failed on hunk #3 with Hijack source tree v477. To add my driver to the latest v477 hijack, you need the attached patch and the driver patch in this post (i.e. attachment one of two).

Please don't use the old time.h patches attachements from the previous posts.

-Techtom
Posted by: Cris

Re: Seeburg Wallbox release, time.h patch for V477 - 13/09/2007 19:36

I think this is one of the coolest things I have seen done with an empeg !!!

Is there any chance of someone putting together a summary of how someone like me might get this working on my empeg, I'd really like to give it a go, but you guys have kinda lost me

From a hardware point of view, I assume the Seeburg unit has the 25v supply connected, with just the pulse output of the unit connected to the empeg via the serial port, am I right ???

This is soooo cool

Cheers

Cris.
Posted by: Cris

Re: Seeburg Wallbox release, time.h patch for V477 - 14/09/2007 19:46

Just re-read my post, I think what I am really asking is can you post a copy of the patched kernel and info on how the whole project can together.

I am sure there are few people here who would love to give something similar a try

Cheers

Cris.
Posted by: techtom

Re: Seeburg Wallbox release, time.h patch for V477 - 15/09/2007 01:54

Quote:
Just re-read my post, I think what I am really asking is can you post a copy of the patched kernel and info on how the whole project can together.

I am sure there are few people here who would love to give something similar a try


I started this thread to answer questions about how to modify the kernel/hijack. I posted kernel patches to allow Mark to include my driver in the hijack release if there was enough interest. Now that the project is finished I'll release a package in the projects section with everything you'll need to interface a seeburg wallbox to your empeg:

    modified v478 HiJack kernel
    my Seeburg application
    instructions to mknod /dev/seeburg and install the application
    simple schematic and parts list for the cable and power supply


I'm on my way back from vacation, but I'll try to get something out late next week.

Techtom
Posted by: Cris

Re: Seeburg Wallbox release, time.h patch for V477 - 15/09/2007 04:11

Quote:
I'm on my way back from vacation, but I'll try to get something out late next week.


Brilliant!

There is no rush of course, my unit is in safe hands in the States until I can figure a cost effective way of shipping it across the pond

Again, cool project

Cheers

Cris.
Posted by: techtom

Seeburg Wallbox -- Schematic - 17/09/2007 05:06

Attached is a simple schematic for the power supply and interface cable. The seeburg interface cable does not interfere with the normal opperation of the serial port. All of the "important" signals are passed through.


-Tecthom
Posted by: techtom

Re: Seeburg Wallbox -- Picture - 17/09/2007 05:09

Attached is a picture of the completed Seeburg interface cable.

-T
Posted by: Cris

Re: Seeburg Wallbox -- Picture - 17/09/2007 06:21

Thanks for the detail! Just what I need

So you are wiring this direct to the serial port on the emepg's wiring harness ?

I wonder if the 50Hz supply here in the UK will effect the pulse times from the Seeburg?

And also I think I have a 200 selection unit, so I guess I may have to learn how to do all this stuff myself anyway

Thanks for the help so far.

Cheers

Cris.
Posted by: mlord

Re: Seeburg Wallbox -- Picture - 17/09/2007 21:26

Hi, *someday* I'll get round to incorporating your patches
into the Hijack source tree. In the meanwhile, if you have any updates,
then just re-post the "diff -u" output against a recent Hijack.

Thanks
Posted by: andym

Re: Seeburg Wallbox -- Picture - 21/09/2007 16:37

Cris, seeing as hacking kernels isn't your thing, why don't you try and use a microcontroller like a Picaxe to fit between your box and your empeg, I bet you'd find it much easier. The Picaxe is a piece of piss to program.
Posted by: techtom

Re: Seeburg Wallbox -- Picture - 21/09/2007 18:59

Quote:
...why don't you try and use a microcontroller like a Picaxe to fit between your box and your empeg, I bet you'd find it much easier.


Actually the work that chris would need to do has nothing to do with the kernel. The kernel collects 256, 10ms samples of the pulses from the seeburg wallbox and the seeburg application parses the samples to identify the button pressed. Chris would need to modify my seeburg app to adjust for the 50Hz driving the motor. My seeburg app uses a big state machine to convert the samples into pulses and the pulses into a button press. So chris only needs to adjust the state machine. If you used the picaxe, you would end up writing the exact same state machine. I looked into a PIC based off the shelf $99 seeburg to rs-232 interface. But there isn't a free serial port on the empeg, so I ended up doing this version.

My seeburg app should work with the 160 and 200 song wallboxes. The app will read up to 200 entries in a play list, but I only have the 100, so I can't test the extra buttons. The app will writeout to disk (assuming rw) the 256 samples when ever the state machine fails. (e.g. badstate_v224.bin) I can post process the file and figure out what went wrong.


-Techtom
Posted by: Cris

Re: Seeburg Wallbox -- Picture - 22/09/2007 05:24

Quote:
Cris, seeing as hacking kernels isn't your thing, why don't you try and use a microcontroller like a Picaxe to fit between your box and your empeg, I bet you'd find it much easier. The Picaxe is a piece of piss to program.


I like the idea. And I think an ultimate goal may be this solution. I had been looking around at other solutions but hadn't seen this product before.

I'd like to develop something that would interface with my slimserver network in the house, say over WiFi. But for now using the empeg seems like a really good idea, it gets used once every 2 weeks or so at the moment and this will put it back into regular usage.

I guess I will have to wait for my unit to turn up and see if it works first

I am still unsure how you build the seeburg driver into Hijack, is it possible to post a patched version here that I could upload just like anyother hijack update?

Cheers

Cris.
Posted by: Cris

Re: Seeburg Wallbox -- Picture - 22/09/2007 05:28

Quote:
I'd like to develop something that would interface with my slimserver network in the house, say over WiFi


Is the empeg capable of sending commands to the slimserver via TCP/IP?

This could be the solution I am looking for! That was I could just hook up to the empeg for local output, or configure it to control any one of the slimserver devices, that would be an awesome end goal, and possibly the cheapest as no extra hardware would be needed

Cheers

Cris.
Posted by: andym

Re: Seeburg Wallbox -- Picture - 22/09/2007 07:50

Yep, shouldn't be a problem. However, if you're going to end up using a slimserver, why don't you just build something that runs on the server instead? Assuming you have a spare serial port on that?
Posted by: julf

Re: Seeburg Wallbox -- Picture - 22/09/2007 09:52

Quote:
However, if you're going to end up using a slimserver, why don't you just build something that runs on the server instead?


Maybe because (at least for me) the server is in the boiler room, and the Wallbox (and speakers) will be 2 floors and half a house away...

Wonder if the code cold be run on a Rio Receiver - hmm, wonder if it can do the serial I/O...
Posted by: andym

Re: Seeburg Wallbox -- Picture - 22/09/2007 12:28

Quote:
Quote:
However, if you're going to end up using a slimserver, why don't you just build something that runs on the server instead?


Maybe because (at least for me) the server is in the boiler room, and the Wallbox (and speakers) will be 2 floors and half a house away...

Wonder if the code cold be run on a Rio Receiver - hmm, wonder if it can do the serial I/O...


The reason I mentioned it is because I know the layout of Cris' house. A rio reciever did cross my mind, I seem to remember reading somewhere that there is a serial port in there somewhere, and the built-in amp would probably come in very useful.
Posted by: Cris

Re: Seeburg Wallbox -- Picture - 23/09/2007 18:07

Quote:
The reason I mentioned it is because I know the layout of Cris' house. A rio reciever did cross my mind, I seem to remember reading somewhere that there is a serial port in there somewhere, and the built-in amp would probably come in very useful.


I think the best solution for my layout would be WiFi/wired TCP/IP control of a streaming device such as the Squeezebox. I say this because the system in my font room is hidden under the stairs, and a wireless platform would be perfect as I could place the wallbox where I like without worrying about getting the audio feed to the amp.

For the moment getting it to work with the empeg would be great

Cheers

Cris.
Posted by: Cris

Rabbit Semiconductor Development Kit - 27/09/2007 13:35

I have purchased a Rabbit Semiconductor 4010 Development Kit, they were on offer at their European Store. Quite reasonable really, I rang the local supplier and they told me that is £17 below cost to them.

I also have the commercial serial adaptor on it's way, I figured my skills in this area are seriously minimal so I needed an easy solution to check everything is working before I start my own development. I did try to contact the guys linked right at the start of this thread, but no joy as yet, he was using a Rabbit board to good effect it seems.

The empeg controlling the slimserver would of course be the ultimate solution for me

Cheers

Cris.
Posted by: Cris

Seeburg Wallbox - Almost Ready - 04/10/2007 16:25

After a mini spending spree on eBay I have several options on their way

I have one in really good condition on it's way from the states, and I have a couple of scrappers I am hoping to make good from here in the UK.

So, to my question. I am still no closer to understanding where I need to start with the empeg side of things, the lead can be made up no probs, but the drivers is still a real puzzle to me, can someone lend a hand here and build up a kernel for me?

Which serial port are you using Tom, the one on the back of the empeg itself or the sled?

Cheers

Cris.
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 00:43

Attached is the archive of my seeburg project. I've included a prebuilt v478 Hijack kernel with my wallbox driver patches, the wallbox app, and schematics for the seeburg interface.

-Techtom


--------------------- Readme.txt-------------------
Installation instructions.

I've included a prebuilt v478 kernel image so you don't need to build it from the source tree.

1) Flash kernel with v478_p_seeburg.zImage. I just ftp "put" v478_p_seeburg.zImage to /proc/empeg_kernel
2) ftp the wallbox app to the /empeg/bin directory on your empeg.
3) connect up to the serial port (without the seeburg adaptor) of your empeg and type the following commands:

q ; stops the player
# rw ; mounts the file system as read/write
# chmod a+rx /empeg/bin/wallbox ; enables the wallbox application to be executed
# mknod /dev/wallbox c 51 0 ; creates the wallbox device

4) to test the wallbox application, find the fid of one of your longer playlists (mine was a7d0) and type

# /empeg/bin/wallbox a7d0 &

5) the wallbox application should have started and read the playlist without errors
6) restart the player by typing:

# player

7) connect the seeburg serial port adaptor (see schematic) to your empeg.
8) insert a coin into your seeburg and select a song.
9) the wallbox application should detect the button press and queue the song from the playlist

10) once this is working, you can add an EXEC_ONCE command to your config.ini file. Make sure everything is working correcly BEFORE you add the EXEC_ONCE command to your config.ini file. If you forget to include the "&" at the end, the empeg will not start the player and you'll need to ftp a new config.ini to the empeg.

;@EXEC_ONCE /empeg/bin/wallbox a7d0 &


-Techtom


PS if you want to build your own kernel, just apply the driver.patch and time_h_477.patch to the latest
hijack kernel source tree.
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 00:49

Quote:
So, to my question. I am still no closer to understanding where I need to start with the empeg side of things, the lead can be made up no probs, but the drivers is still a real puzzle to me, can someone lend a hand here and build up a kernel for me?


The Seeburg.zip attachment in my previous post should have every thing you need. I don't know if it will work with a seeburg running on 50Hz. My advice to you is to get a small 100w 60hz inverter and run the seeburg off of that.

Quote:
Which serial port are you using Tom, the one on the back of the empeg itself or the sled?


The serial port on the back of the empeg.
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 13:14

Thanks, this is great!

I have all the stuff together (inc a sort of working seeburg!) just need to find the time to put it all together now.

60Hz transformers are quite expensive I think, at least I haven't seen any readily available, so I'm going to try it at 50Hz 25v AC and see how I go on.

Update soon

Cheers

Cris.
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 16:34

Quote:

60Hz transformers are quite expensive I think, at least I haven't seen any readily available,


I was suggesting using a cheap $24 inverter like this one http://www.walmart.com/catalog/product.do?product_id=4965458. That would get you 120V @ 60hz. You can use any 50HZ transformer, as long as the ratio is correct. e.g you could use a 220V:48V @50Hz transformer connected to the output of the 120V inverter. You would get 24V @ 60hz.

Quote:

...I'm going to try it at 50Hz 25v AC and see how I go on.


Mount the filesystem RW before running the wallbox app. When the state machine fails, it dumps the 256 samples to a file called "badstate_7xx.bin" where the 700 number is the state that failed. Send me the bin file and I can see if it is an easy fix.

The format of the file is very simple. It's just 256 four byte words where the LSB is the state of the seeburg switch and the upper 31 bits are the accumulated count of system time ticks.

-Techtom
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 17:35

Thanks for the tips

I will give it a go with the 230v to 25v @50Hz transformer I have and see how it works.

I have been messing around with the "scrap" wall boxes I got hold of and have got a working 3W1 like yours out of them so far. Well I say working I am having trouble with a leaf switch just to the left of the motor. It seems to be worn, and the adjustment is very fine, but I can get it to select what I want now

They really are amazing devices, it's all a bit like black magic how it works, but as I make my way around the mech I am starting to make sense of it all.

I also have all the parts for the serial lead, so in the next couple of days I should have the chance to get it all up ad running.

Thanks again, I'll post here when I get it hooked up and working (or not!)

Cheers

Cris.
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 20:28

I couldn't resist

I got out the soldering iron and hooked it all up. It kinda works too....

Code:
Starting bash.
empeg:/empeg/bin# rw
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
empeg:/empeg/bin# /empeg/bin/wallbox 83b0 &
[1] 103
empeg:/empeg/bin#
Seeburg Wallbox Application Version 1.0 by Scott Swazey
Read 200 items from playlist 83b0

player
Timezone: Atlantic/South_Georgia
Hijack: intercepting config.ini

player.cpp : 564:empeg-car 3.00-alpha7 2004/02/13.
Prolux 4 empeg car - 2.1490 Feb 13 2004
Vcb: 0x4070e000
bad state 778, button 0, letter 0, ticks 18
Logged 256 samples to /bad_state_778.bin



Edit - Durr found file in root, find it attached.

So I am happy that it seems to work ok, just the 50Hz problem I think

Cheers

Cris.
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 21:39

You didn't say what button you pressed and doesn't look right quite right. For even letters (A,C,E,G,J) it should send the # of pulses followed by a long low. then it will stay high for 200ms and then it will pulse the letter pair (AB=1, CD=2, etc) followed by all high. (see attached image of your bad_state_778 and button A02)

For even letters (B,D,F,H,K) it will send 10 + # pulses followed by 200ms high and then the pulse of the letter pair as above.

In your case, it means the contacts are dirty or broken.

-Techtom
Posted by: tfabris

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 21:56

Shouldn't it debounce?
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 21:58

If you have access to a linux host you can convert the bad_state.bin file into a format that excel can read. Use the following command:

# od -td4 -w4 bad_state_778.bin > bad_state_778.txt

Open the .txt file in excel. Do not double click to open it. You must choose the File->Open command in Excel to open bad_state_778.txt. Choose Fixed width and you should have a spread sheet with two columns (not all the data in one).

Open the attached spread and copy the second column of bad_state778.txt into Column "B" of the attached spread sheet. Look at the top chart to see if the data is correct.

Based on the state 778 and the tick count (18), 50Hz will not work with the current wallbox application. I can probably write a 50hz version, but I will need the "bad_state_7xx.bin" for the following Buttons A1,B2,E5,F5,J10,K10. Don't send them to me until you've plotted them using the attached spread sheet to confirm that they are correct. Your current wallbox is clearly broken... Sorry

-Techtom
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 08/10/2007 22:01

Quote:
Shouldn't it debounce?

Yes, it does. But this not a debounce problem. The waveform is wrong.

The driver is just a 10ms sampler. When the CTS line goes low, the driver collects the state of the CTS pin every 10ms for the next 2.56 seconds. The wallbox app tries to convert the samples into pulses and the pulses into buttons. If the app can't, it just writes out the samples, untouched. Plotting the samples from a 50Hz wallbox, should show the correct waveform, but with longer pulses. The app can't convert it to a button, but the plot should still be correct.

-Techtom
Posted by: tfabris

Re: Seeburg Wallbox - Release 1.0 - 09/10/2007 03:23

Quote:
Yes, it does. But this not a debounce problem. The waveform is wrong.

Ah, *that* makes perfect sense. Carry on!
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 09/10/2007 04:32

Quote:
Your current wallbox is clearly broken... Sorry


Well I don't find that hard to believe, I will get some contact cleaner etc... and give it another go. That was for button A1.

How many times should the selector be going round? It only goes round once per selection at the moment, maybe I'll try and take a video when I get home tonight. As I said the box is in a pretty bad way, but seems to function as it should on the most part.

Cheers

Cris.
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 09/10/2007 05:40

Quote:
Quote:
Your current wallbox is clearly broken... Sorry


Well I don't find that hard to believe, I will get some contact cleaner etc... and give it another go. That was for button A1.


Hmm it doesn't look anything like A1. See the attached comparison of J10 and A01.

Quote:

How many times should the selector be going round? It only goes round once per selection at the moment


one complete rotatation of the pulsing dial. The coin counter will advance one step for each selection.

Quote:

As I said the box is in a pretty bad way, but seems to function as it should on the most part.


The motor may be running, but it's not pulsing correctly. Have you been able to load up one of the bad_state_7xx.bin file into excel? Collect bin files for A01 & J10 and compare them to the attache logic analyzer file.

-Techtom
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 09/10/2007 09:40

When I get home I'll post a picture of the pulse wheel, I think it may be starting from the wrong posistion.

I don't have linux here (apart from a clarckconnect server could try it on that) so I haven't been able to get the files into excel, I'll try that later, but it is very interesting to see your results. I am thinking it may be something to do with the wiring behind the selection buttons, the mech seems to have been adjusted sometime in the past and that could be effecting the switch contact ???

Cheers

Cris.
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 09/10/2007 14:31

I have made a short video to show you the problem I have with this Seeburg unit, you can download it [REMOVED].

I think I am on top of the problem, and can see why the previous files looked so wrong. I will do some more fiddling...

Cheers

Cris.
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 09/10/2007 15:50

I have made a change to the position of the pulse arm a little bit, it looks like it had slipped somehow, it seems to be operating much better.

I have dropped the data into the Excel document and it looks much better, I am getting some strange results with the other selctions, but I think I have a few more adjustments to make.

Does this look more like it?

Cheers

Cris.
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 09/10/2007 16:12

Quote:

I have dropped the data into the Excel document and it looks much better, I am getting some strange results with the other selctions, but I think I have a few more adjustments to make.

Does this look more like it?


Yes, it looks perfect. Now collect the the bad_state_7xx.bin files for the following buttons: A1,B2,E5,F6,J10,K10 and put them in a zip file. I'll take a look creating a version for 50Hz.

BTW B2 will look like 12 pulses and then 1 pulse. K10 will look like 20 pulses then 5 pulses.

-Techtom
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 09/10/2007 16:30

Here is what I have so far.

I am finding that 2 lots of samples are being taken for J10 nad K10, with number of ticks being 16, 17 or 18 (it seems to be random?).

Any ideas what's going on? I was thinking that the sample period may not be long enough so it starts the process again, for example K10 seems only to show the last 5 pulses.

Code:
bad state 778, button 0, letter 0, ticks 16
Logged 256 samples to /bad_state_778.bin
bad state 778, button 0, letter 0, ticks 18
Logged 256 samples to /bad_state_778.bin


Above is what is output when K10 is selected, the numbers of ticks changes but there are always 2 files, sometime the state is 770.

Cheers

Cris.

WOOT - 1000th post
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 10/10/2007 00:13

Quote:
I am finding that 2 lots of samples are being taken for J10 and K10

Any ideas what's going on? I was thinking that the sample period may not be long enough so it starts the process again.


Yes, you are correct. It's is taking longer than 2.56 seconds to send K10 on your wallbox. The worst case pulse time on your 50Hz wallbox is about 114.5 msec. My 60Hz wallbox worst case pulse time is 76.5ms. I would have expected the worst case pulse time of a 50Hz box to be 60/50*76.5ms = 92ms. Your box seems slow, you might want to try another wallbox, or try a slighly higer voltage, say 28-30V. Do the lights look nice and bright? Can you measure the AC voltage at the imput terminals when the motor is running?

-Techtom
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 10/10/2007 04:52

Quote:
Can you measure the AC voltage at the imput terminals when the motor is running?


Yea, it holds at 25v. The lights are nice and bright and are not effected by the motor running. The transformer I am using is pretty beefy, it does also have a 30v output, but I didn't want to stress the components too much.

The other boxes are not currently in a working state, this was the best of the bunch, but maybe I should give it up as a bad job?

I have a 200 selection unit on it's way. This is in much better condition, but hasn't turned up here due to the postal strike. MAybe I should wait for that to turn up.

Cheers

Cris.
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 10/10/2007 05:10

Quote:
or try a slighly higer voltage, say 28-30V


Ok this is interesting.

I timed the pulse arm at 25v to be just over 4 seconds, at 30v it's 5.4 seconds !!! Weird !!!

The light also look overly bright at 30v, so I don't think that it a very good idea. Worth a try though

Cheers

Cris.
Posted by: larry818

Re: Seeburg Wallbox - Release 1.0 - 10/10/2007 13:52

Just curious, do you have a real transformer or some kind of chopping supply?
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 10/10/2007 15:26

Not really sure what you are asking.

It's just a normal transformer, not in a case or anything, I am not sure what it is rated at but it seems to hold up just fine under the load of the seeburg.

When I says it's beefy it must weight 4kgs+

I can take a picture if you think that may have something to do with it???

Cheers

Cris.
Posted by: tman

Re: Seeburg Wallbox - Release 1.0 - 10/10/2007 16:21

Quote:
Not really sure what you are asking.

It's just a normal transformer, not in a case or anything, I am not sure what it is rated at but it seems to hold up just fine under the load of the seeburg.

Some inverters/SMPS will output something that is AC but not actually a proper sine wave. Usually things won't care but certain devices with motors in them will and act oddly because of this.
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 10/10/2007 17:08

Nothing fancy, just a normal transformer...



Cheers

Cris.
Posted by: techtom

Re: Seeburg Wallbox - Release 1.0 - 10/10/2007 20:15

Quote:

Ok this is interesting. I timed the pulse arm at 25v to be just over 4 seconds, at 30v it's 5.4 seconds !!! Weird !!!


Hmm, try 20V then... I'haven't timed my pulse arm, but I Timed it just now using my youtube video http://www.youtube.com/watch?v=f3Z31FvUHMo It's about 2 seconds from the time I press F10 to the "click" at the end of the selection. This is consistent with my earlier analysis that the 2.56sec should be more than enough to sample the pulses.

To extend the sample time I would need to rewrite the driver code to add an IOCTRL to expand the sample buffer. I never done IOCTL, but it should be possible. For 50Hz the wallbox app state machine will need to be completely rewritten.

It's probably easier for me to send you a $24 110V@60Hz inverter and a $20 radioshack transformer, assuming you''l cover the cost+shipping.

-Techtom
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 10/10/2007 20:27

Quote:
It's probably easier for me to send you a $24 [Email]110V@60Hz[/Email] inverter and a $20 radioshack transformer, assuming you''l cover the cost+shipping.


Thanks for the offer

Before I take that option I will wait for my other box to turn up, or even try to get the other 3W1 I have here to power up. I also have a PC PlayBox 2 on it's way which is said to support 50Hz operation. I figured I could use it to figure out if it's my Seeburg that is faulty or the fact the arm is supposed to take that long on 50Hz.

For some reason I don't like the idea of the 230v AC 50Hz > 12 DC > 110v AC 60Hz > 25v AC 60Hz sequence. Too many boxes

Thanks for all your help with this, I know I am such a pain in the ass

Is anyone else giving this a try ?

Cheers

Cris.

Edit - Just noticed this transformer I have here has a 110v input! Cool!
Posted by: julf

Re: Seeburg Wallbox - Release 1.0 - 11/10/2007 09:21

Quote:
Is anyone else giving this a try ?


Waiting for the hardware to arrive...
Posted by: JBjorgen

Re: Seeburg Wallbox - Release 1.0 - 11/10/2007 11:25

Strongly considering it. I won't be installing my Empeg in my Jeep, so I need to find another semi-practical use for it.
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 11/10/2007 14:06

Quote:
Edit - Just noticed this transformer I have here has a 110v input! Cool!


What is not so cool is that the mains in my area seems to have gone up to 250v. This means the output of the transformer is not 27.5v and I think this explains the problems I am seeing. If the higher the input voltage the slower the arm, then I have found my Gremlin.

Funny, when I first tested this transformer all the voltages checked out ok, but now I am using it the input voltage has jumped a little. Bugger!

What sparked this retesting off is the fact that the PC Playbox2 doesn't work either! (even at 50Hz setting).

Anyone good as PSU design ?

Cheers

Cris.
Posted by: andy

Re: Seeburg Wallbox - Release 1.0 - 11/10/2007 14:21

Quote:

What is not so cool is that the mains in my area seems to have gone up to 250v.

Mine has been up above 250v for most of this year, regularly triggering my UPS's trim feature. As of last week it now is down near 220v, regularly triggering my USP's boost feature. A series of big droops this week as well, enough to take the ADSL line down.
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 11/10/2007 14:35

I have just spent the best part of an hour fault finding on one of the other wall boxes, this one is a 3WA 200 selection. I dropped lucky and found a contact with the case on one of the wires running to the "Dual Pricing Unit". Something is still wrong as it seems to be on freeplay, but it is sending pulses.

Same as with the other wallbox, doesn't work with PC Play, so I assume my power source is the problem Project back on hold until I can find a workable solution.

Anyone got any tips?

Cheers

Cris.
Posted by: tman

Re: Seeburg Wallbox - Release 1.0 - 11/10/2007 21:34

Quote:
Quote:

What is not so cool is that the mains in my area seems to have gone up to 250v.

Mine has been up above 250v for most of this year, regularly triggering my UPS's trim feature. As of last week it now is down near 220v, regularly triggering my USP's boost feature. A series of big droops this week as well, enough to take the ADSL line down.

UK mains voltage is 230 V +10% -6% (216.2V - 253V). Anything within those ranges is still in spec has to be handled by your equipment. If its higher or lower than you can report it as a fault.
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 13/10/2007 14:32

Quote:
Waiting for the hardware to arrive...


So what's your plan for the PSU? I imagine you may have similar problems to me.

Edit - Today I found out I am a complete idiot! I have just got PC PlayBox to work fine on my current PSU, so the previously posted samples are correct for 50Hz operation. So it looks as if my wallboxes (not tried the 200 selction unit yet) are working within spec, I assume this mean getting it to work with the empeg maybe out of my reach for now ???

Cheers

Cris.
Posted by: julf

Re: Seeburg Wallbox - Release 1.0 - 14/10/2007 05:48

Planning to use a simple stepdown transformer. Have to look at the timings with a scope....
Posted by: Cris

Re: Seeburg Wallbox - Release 1.0 - 22/10/2007 15:28

If you ever need a manual I can recommend eBay seller "nikondave", I have just taken delivery of a very nice complete set that has already answered a few questions I had, well worth the $$$ if your unit plays up.

Cheers

Cris.
Posted by: techtom

Seeburg wallbox -- Title Strip Form - 03/01/2008 06:21

Attached is a PDF form that will create Title Strips for a Seebug Wallbox. I found it on the Internet and fixed a couple of bugs / alignment errors in the form. It will now correctly auto-size the font on long text strings.


-Techtom
Posted by: techtom

Wallbox application problem. - 03/01/2008 06:40

I'm just about to release the source to my wallbox application. But, I still have one bug... If I leave the empeg on all the time, it will not play the first song selected. It correctly Queues the song, but it does not play. If I manually press play, the song plays. Everything works fine, but after a few hours, the first song will queue but not play.

It has to be something to do with the way the empeg "sleeps" when at the "end of playlist"

I know the driver code is correctly determining the state of the empeg, because it looks at empeg_notify->sound and sees that the player is stopped, so it queues the song (no append) which wipes out the previously queued playlist (which had already finished). The driver then sends the "space" character to the player. Usually, the empeg player app will start playing the song that the wallbox app just queued. But if the empeg has been sitting at "end of playlist" for a few hours, it acts as if it is ignoring the "space" charater I sent to start the player.

Any Ideas?

-Techtom

BTW anyone besides me actually using it? smile
Posted by: JBjorgen

Re: Wallbox application problem. - 03/01/2008 14:03

I'm still interested
Posted by: wfaulk

Re: Wallbox application problem. - 03/01/2008 14:12

This is a wild guess, but if it's going to sleep for whatever reason, a button press just wakes it up; it doesn't also use that button press as a command.
Posted by: mlord

Re: Wallbox application problem. - 03/01/2008 14:19

Originally Posted By: wfaulk
This is a wild guess, but if it's going to sleep for whatever reason, a button press just wakes it up; it doesn't also use that button press as a command.


Good thinking.

Take a look at the Hijack menu, and ensure that the "Screen Blanker Timeout" is set to "[Off]", to prevent Hijack from putting the player to sleep.

-ml
Posted by: techtom

Re: Wallbox application problem. - 03/01/2008 20:21

Originally Posted By: mlord

Take a look at the Hijack menu, and ensure that the "Screen Blanker Timeout" is set to "[Off]", to prevent Hijack from putting the player to sleep.


I checked my empeg and "screen blanker timeout" is set to: 00:15.

I'll check tonight to see if setting it to "off" fixes the problem...

I would still like to use the screen blanker because most of the time the empeg is not playing songs, so I don't want to burn in "end of playlist" into my display.

so I have a few questions:

  1. How do I detect that hijack has blanked the screen
  2. If the screen is blanked, how do I wake up the display?
  3. curently, I send '#'<FID><newline><space><newline> e.i. "#fid\n \n" to the hijack serial insert routine. Should I break this up into two calls to serial_insert? The second call would just be <space><newline>.


Thanks,

-Techtom
Posted by: mlord

Re: Wallbox application problem. - 03/01/2008 23:25

To avoid burn in, you may have to code up a quick userspace app that takes over the display and simply clears it until the next button press. Or hack hijack to do the same.

You cannot power off the screen easily, though. We tried that once, and it had serious issues.

EDIT: Oh wait, you can still use the screen blanker.
Here is what you need to do instead,
to prevent it from putting the player into standby:

In the config.ini file:

[hijack]
standby_minutes=0



Posted by: techtom

Re: Wallbox application problem. - 04/01/2008 01:42

Originally Posted By: mlord

EDIT: Oh wait, you can still use the screen blanker.
Here is what you need to do instead,
to prevent it from putting the player into standby:

In the config.ini file:

[hijack]
standby_minutes=0


But what exactly does Hijack do when it puts the player into standby and how does it bring it out of standby? My driver queues the playlist from kernel space so I should be able to see any of the hijack state variables...

Thanks,

-Techtom
Posted by: mlord

Re: Wallbox application problem. - 04/01/2008 14:08

Originally Posted By: techtom

But what exactly does Hijack do when it puts the player into standby and how does it bring it out of standby? My driver queues the playlist from kernel space so I should be able to see any of the hijack state variables...


It injects a long press of the RioRemote "Source" button, the same as a human would do to put it into standby.

Hijack does NOT bring it back out of standby -- somebody has to press a button for that to happen.

Cheers
Posted by: mlord

Re: Wallbox application problem. - 04/01/2008 14:11

The relevant code looks like this:
Code:
if (blanker_triggered) {
        unsigned long minimum = blanker_timeout * (SCREEN_BLANKER_MULTIPLIER * HZ);
        if (jiffies_since(blanker_triggered) > minimum) {
                buf = player_buf;
                memset(buf, 0, EMPEG_SCREEN_BYTES);
                refresh = NEED_REFRESH;
                if (is_paused && hijack_standby_minutes > 0) {
                        if (jiffies_since(blanker_triggered) >= ((hijack_standby_minutes * 60 * HZ) + minimum)) {
                                save_flags_cli(flags);
                                hijack_enq_button_pair(IR_RIO_SOURCE_PRESSED|BUTTON_FLAGS_LONGPRESS);
                                restore_flags(flags);
                                blanker_triggered = jiffies - minimum;  // prevents repeating buttons over and over..
                        }
                }
        }
}

Posted by: techtom

Re: Wallbox application problem. - 04/01/2008 22:48

Originally Posted By: techtom
But what exactly does Hijack do when it puts the player into standby and how does it bring it out of standby?


OK it looks like "hijack_enq_button_pair(IR_RIO_SELECTMODE_PRESSED);" will bring it out of standby

But I'm still not sure how to detect that the empeg has been "IR_RIO_SOURCE_PRESSED|BUTTON_FLAGS_LONGPRESS" into standby.

OR...
Can just call "hijack_enq_button_pair(IR_RIO_SELECTMODE_PRESSED);" every time I see the player is stoped (notify->sound==0) and I'm queuing a song?


BTW... Standby is definitely causing the problem. When I disable standby, the problem goes away

-Techtom
Posted by: tman

Re: Wallbox application problem. - 04/01/2008 23:17

/proc/empeg_power shows various flags. any of them useful for you?
Posted by: mlord

Re: Wallbox application problem. - 05/01/2008 01:45

Why not just disable the standby then?

All that standby does, is turn off the VFD
(and stop playing if in a playlist).

That's about it, really.

But if you want to detect it from userspace,
look at /proc/empeg_power, at the "Display on" line.

If 1, then NOT in standby. If 0, then YES in standby.

Inside the kernel, The "struct display_dev" structure has a "power" bool: 0==standby, 1==not_standby. This is the same variable that is exposed in /proc/empeg_power:Display-on.

Hijack uses it ("dev->power") in several places inside hijack.c

Cheers
Posted by: JBjorgen

Re: Wallbox application problem. - 06/02/2008 16:13

How's this coming along? I'm still very interested.
Posted by: techtom

Re: Wallbox application problem. - 25/02/2008 17:32

Originally Posted By: JBjorgen
How's this coming along? I'm still very interested.


It's finished. It works for a seeburg 100 using 60Hz power. I don't think the UK guys were able to get it to work on 50Hz. I've been using it for the last few months. Mark's sugestion fixed the only problem I was having:

Originally Posted By: mlord

In the config.ini file:

[hijack]
standby_minutes=0



All the files are in attachments to the posts.

-Techtom