Yes, each frame of DMX512 data contains all current values. So you can drop every other frame and you get the full data, though obviously with some lumpiness if things are changing.
Other strategies you could persue include sending less channels, or you you could encode the data so it takes up less bandwidth, though that would involve dealy of a frame, which probably wont be an issue.
The DMX512.com Forum
- December 24, 2024, 01:19:59 PM
- Welcome, Guest
News:
SMF - Just Installed!
|
51
General Category / DMX512 Discussions / Re: strategy to reduce baudrate by purposely dropping frames? Does DMX constanlty re
on: June 05, 2010, 03:44:43 AM
|
||
| Started by intellijel - Last post by DMX512 | ||
|
52
General Category / DMX512 Discussions / strategy to reduce baudrate by purposely dropping frames? Does DMX constanlty re
on: May 30, 2010, 09:57:27 PM
|
||
| Started by intellijel - Last post by intellijel | ||
|
I have an arduino (microcontroller) device that happily receives DMX512 at it's expect baud rate of 250kbps.
The problem is that I want to take particular DMX values and transmit them wirelessly via xbee modules which can only handle a max baud rate of 115200 kbps (less than half). As a solution I thought about just skipping every other frame of DMX data so that I am effectively cutting the data rate in half. However I am not clear from reading the protocol description if DMX is constantly re-sending the same values (even if they have not changed)? e.g. If I send a value of 112 on byte one of the 512 byte frame (and zero on everything else then I would be sending frame1:[112][0][0]...[0] Assuming I did not make any changes on my DMX controller, would it keep sending the same frame values as last sent? e.g. frame2:[112][0][0]...[0] frame3:[112][0][0]...[0] frame4:[112][0][0]...[0] etc. If this is the case then I can probably afford to skip a frame or two. |
||
|
53
on: March 28, 2010, 09:52:47 PM
|
||
| Started by tendai02 - Last post by tendai02 | ||
|
thank you very much for the advise. the reason why i am using PWM is because it is one of the conditions in my final year project. so in this project, the pulse-width-modulation will be used to dim the LED light using the signal from a DMX512 console or generator which can produce the DMX512 signal. at the moment, i am using a Velleman USB controlled DMX interface to get my DMX512 signal.
|
||
|
54
on: March 28, 2010, 09:07:05 PM
|
||
| Started by tendai02 - Last post by DMX512 | ||
|
DMX512 reception uses asynchronous comms, so the fact the simulator doesn't support a mode you're not using is not a problem. Those are just warning messages anyway.
In terms of debugging - start simple - dont try to get PWM up intially, settle for a LED going on and off. The three tools I find most helpful for PIC debugging is the on-board ICD with MPLab's free software, a LED or two attached to pin(s) and a scope (or a counter / timer) for timing things. With real-time stuff you cant single step your way through code with the ICD, but you can use breakpoints and examine data which is really helpful. |
||
|
55
on: March 28, 2010, 11:40:35 AM
|
||
| Started by tendai02 - Last post by tendai02 | ||
|
hi guys
i have assembled my program without any errors and have run the MPLAB SIM and iget the following message. does it affact my program form running after loading to my PIC16F876 here is the message Code: [Select] UART-W0005: Synchronous mode is not implemented in USART. Use Asynchronous mode only.please help thank you in advance |
||
|
56
on: March 26, 2010, 08:43:52 PM
|
||
| Started by tendai02 - Last post by tendai02 | ||
|
i was trying to load a .asm file from MPLAB IDE v8.43 to the MPLAB v 5.2 which comes with the Velleman K8048 programmer. so i have been able to load the hex file using the functions in the PicProg2009 software. now when i load the hex file and try to run the program from the PIC16F876, nothing happens
i have tried to change the coding but still nthing happens when i test the voltages on the pins iget the following pin 9 with respect ot ground = 1.85V pin 10 wit respect to ground = 2.55V pin 9 and 10 are the external 20MHz connections(crystal oscilator) pin 18 (RC7 DMX input has 4.97V from the TIL194 opto-isolator) opto- isolator gets the biasing voltage from pin1 of the max485 chip which is connected to the DMX512 line my proposed output pins for PWM are RC0, RC1 and RC2 of the chip and i get 0.1V from them which is not high enough to switch on the transistors driving the High brightness LEDs |
||
|
57
on: March 26, 2010, 07:27:33 PM
|
||
| Started by tendai02 - Last post by DMX512 | ||
|
Could you be more specific as to the "problems"?
|
||
|
58
on: March 23, 2010, 03:46:12 PM
|
||
| Started by tendai02 - Last post by tendai02 | ||
|
hi guys
i have a Velleman K8048 programmer and it seems to give me problems everytime i try to assemble my .asm file from MPLAB v8.43 so i can load the hex file to the PIC16F876. it gives me errors which i do not get when i use the v8.43 to create hex files the Velleman comes with MPLAB IDE v5.2. could it be the different versions of MPLAB which cause the problems when assembling? please help thank you in advance |
||
|
59
on: March 19, 2010, 09:12:00 PM
|
||
| Started by tendai02 - Last post by DMX512 | ||
|
The PIC isn't a bad choice of processor for this trick, as it has count / compare thingies, which I think could be persuaded to do most of the work for you.
|
||
|
60
on: March 19, 2010, 09:40:28 AM
|
||
| Started by tendai02 - Last post by tendai02 | ||
|
i think that is a brilliant idea, i never thought of it. i am a newbee on the PIC microcontroller programming. i will see if i can add it to my circuit
thnk you for the information |
||